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
