- From: Gavin Peters <gavinp@chromium.org>
- Date: Wed, 15 Sep 2010 13:45:02 -0400
Hi, I'm working on link tags inside of chrome. We're now experimenting with an optimization that uses link tags and headers to avoid round trips for cache validation in many cases. I propose we add an optional etags & last-modified attribute to the link element. If present for an http uri, these tags represent an assertion about the current cache status of the target resource. A browser that has a cached resource for that uri with the same etags and/or last-modified may present the link data without validation in connection with the link retrieval. A browser that has a cached resource for that uri which has a different etags and/or last-modified should treat the resource as if it is in need of validation for retrieval, even if normal cache expiry would treat the resource as valid. I anticipate that these attributes will be more commonly (and probably safely) used on the Link: header than in the link element. When used, they have the potential to save a browser many round trip cache validations (304s) even for data with short cache expiry, and to also to potentially allow early cache-expiry for resources which change ahead of their cache validity period. These are both great speedups; page loads should be faster and network use should be reduced. There may be some slight security considerations for these attributes; in particular, if a server or document provides a link element with incorrect or invalid etags, it could cause the wrong resource to be displayed. However, in practice, I think this is unlikely: to do this, you would have to know the etags of the version that is in the client's cache; if you were wrong, of course the browser would do a validation. Does anyone see any holes with this? Is there any reason that we shouldn't add this to the spec? It is fully backward compatible with link tags today, since these are optional attributes, and any browser not recognizing these attributes will just perform some cache-validations, just as they do today. These attributes should speed up browsers that support them without changing behaviour of other browsers that don't. - Gavin (thank you to Mike Benna @ Strangeloop for suggesting these attributes to us!) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100915/e73835e9/attachment.htm>
Received on Wednesday, 15 September 2010 10:45:02 UTC