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

Gavin Peters (蓋文彼德斯) gavinp at chromium.org
Wed Sep 15 10:45:02 PDT 2010


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


More information about the whatwg mailing list