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

[Mike Belshe]

On Sun, Sep 19, 2010 at 11:25 PM, Julian Reschke <julian.reschke at gmx.de>wrote:

> On 20.09.2010 02:37, Aryeh Gregor wrote:
>
>> ...
>>
>> Sure it would.  You can currently only save an HTTP request if a
>> future Expires header (or equivalent) can be sent.  A lot of the time,
>> the resource might change at any moment, so you can't send such a
>> header.  The client has to check every time, and get a 204, even if
>> the resource changes very rarely.  If you could indicate in the HTML
>> source that you know the resource hasn't changed, you could save a lot
>> of round-trips on a page that links to many resources.
>>
> > ...
>
> Resources that should be cached (stylesheets, images) but change at
> unexpected times are indeed a problem.
>
> A well understood approach is to push some kind of version indicator into
> the URI (such as query parameter).
>

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
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.

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.

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.

Mike







>
> Best regards, Julian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100920/8a70ad82/attachment-0002.htm>