[whatwg] Proposal: add attributes etags & last-modified to <link> element.

[Julian Reschke]

On 20.09.2010 17:26, Mike Belshe wrote:
> ...
> LINK, in general, allows a server to indicate to a client that it will
> need a particular resource earlier than the client otherwise would have
> discovered it.  Today, the LINK header doesn't assist with understanding
 > ...

Sorry?

That may be a use case that *could* be implemented using LINK, but it's 
certainly *not* the general use case.

For instance, it doesn't seem to be true for any of the currently used 
link relations in wide use, such as "icon" or "stylesheet" (there's no 
"later" discovery at all).

Or are you referring to using the Link *header* in addition to an 
equivalent HTML <LINK>?

> existing cache control mechanics, so if the browser does have the
> resource in cache but it needs validation, you didn't accomplish what
> you had hoped with the LINK header - the client is still going to make a
> costly round-trip.  For savvy content authers, they could, as you
> suggest, simply modify the content to work with this case.  This
> effectively restricts the full benefit of LINK to the subset of
> resources which are static and have long-lived expiry.  That would leave
> LINK less useful to large swaths of the internet where they do leverage
> if-modified-since and etags.

Link relations cover many other use cases than those that you seem to be 
considering.

For resources that change infrequently but at unexpected times, it's 
already possible to get what you want by varying the URI when the 
resource changes (such as putting a timestamp or a revision number into 
a query parameter).

> Rather than ask this question about the LINK header attributes, you
> could instead aim your question at HTTP - why does HTTP bother with
> if-modified-since?    But the answer is moot - that decision was made
> long ago.

Not sure what you're referring to. If-Modified-Since predates ETags (as 
far as I recall).

> Given that the web *does* use these basic cache control mechanisms, why
> *wouldn't* you want the LINK header to be capable of using them too?
>   :-)  This proposal is actually just making LINK more like the rest of
> HTTP.

My main concern is that if we put etags into *HTML* links, we're leaking 
protocol-level information into markup. I think it would be good if we 
could avoid that, and so far I haven't seen any use case that doesn't 
work without.

Best regards, Julian