- From: Mike Belshe <mike@belshe.com>
- Date: Mon, 20 Sep 2010 08:26:40 -0700
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.htm>
Received on Monday, 20 September 2010 08:26:40 UTC