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

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
> us!)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100917/de92fce1/attachment-0001.htm>

Received on Friday, 17 September 2010 11:31:24 UTC