[whatwg] Proposal: add attributes etags & last-modified to <link> element.
mike at belshe.com
Fri Sep 17 11:31:24 PDT 2010
Sounds great to me.
2010/9/15 Gavin Peters (蓋文彼德斯) <gavinp at chromium.org>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg