Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On Thu, 9 Dec 2010, Roger Hågensen wrote: On 2010-12-08 20:44, Ian Hickson wrote: On Mon, 20 Sep 2010, Roger Hågensen wrote: It would be better to define this as explicitly indicating which resources are NOT valid any longer, with most sites/web applications this would only be a select few links. Doing that would require knowing what the browser's cache contains. Actually it would help the browser to display content faster and with less bandwidth use, as the html document would have last-modified for link elements, the browser then just checks if the linked element is cached and if it is, is the last-modified different. While currently the browser would make a last-modifed http header request for the link element. A link or script with a href is less likely to change than the html contents on the majority of sites, so being able to hint to the browser that this css or that javascript was not changed saves the browser the (multiple) roundtrips to check if the last-modified of the css or js file. So a last-modifed just lets the web author tell the browser cache that the link is stale or not stale. So it's: 1. http header or http get of html, if not cached or stale or cache heuristics thinks that last-modified should be re-checked. 2. do the same with all hrefs, sources etc. in the html document. vs 1. same as 1 above but last-modified hinting of href and src allows the browser to skip step 2 (in well authored or well made template based pages obviously). Damn. I think I skewed this whole topic away from it's original subject to last-modified being supported by all link/href/src etc. in html in general. Which may not be a bad idea really, as a last-modified=timestamp_here (timestamp is http://www.ietf.org/rfc/rfc2822.txt ) would only be a few bytes vs a http header call or a full http get call and added to that the latency/delay in addition. Shortening last-modified to modified might be something to consider as well. You can basically already do all this by just encoding the last-modified-date into the URL and giving the file a huge expiry time. When the URL changes, the browser knows to fetch a new file. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 2010-12-08 20:44, Ian Hickson wrote: On Mon, 20 Sep 2010, Roger Hågensen wrote: It would be better to define this as explicitly indicating which resources are NOT valid any longer, with most sites/web applications this would only be a select few links. Doing that would require knowing what the browser's cache contains. Actually it would help the browser to display content faster and with less bandwidth use, as the html document would have last-modified for link elements, the browser then just checks if the linked element is cached and if it is, is the last-modified different. While currently the browser would make a last-modifed http header request for the link element. A link or script with a href is less likely to change than the html contents on the majority of sites, so being able to hint to the browser that this css or that javascript was not changed saves the browser the (multiple) roundtrips to check if the last-modified of the css or js file. So a last-modifed just lets the web author tell the browser cache that the link is stale or not stale. So it's: 1. http header or http get of html, if not cached or stale or cache heuristics thinks that last-modified should be re-checked. 2. do the same with all hrefs, sources etc. in the html document. vs 1. same as 1 above but last-modified hinting of href and src allows the browser to skip step 2 (in well authored or well made template based pages obviously). Damn. I think I skewed this whole topic away from it's original subject to last-modified being supported by all link/href/src etc. in html in general. Which may not be a bad idea really, as a last-modified=timestamp_here (timestamp is http://www.ietf.org/rfc/rfc2822.txt ) would only be a few bytes vs a http header call or a full http get call and added to that the latency/delay in addition. Shortening last-modified to modified might be something to consider as well. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On Wed, 15 Sep 2010, Gavin Peters (�~S~K�~V~G彼德�~V�) wrote: 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. As others have pointed out, these don't seem to add anything to the equation that couldn't also be handled by simply changing the URL and giving the resources essentially infinite cacheable lifetimes. In both cases, the HTML document has to be changed (in the same location even). The advantage of the URL trick is it works today, and is probably easier to understand (most authors are unlikely to know how to find their ETags even if they knew what they were, for instance). On Mon, 20 Sep 2010, Roger Hågensen wrote: It would be better to define this as explicitly indicating which resources are NOT valid any longer, with most sites/web applications this would only be a select few links. Doing that would require knowing what the browser's cache contains. I haven't added this to the spec yet. However, I encourage experimentation -- that's how we work out what the spec should say; if this turns out to be popular and effective, we should reconsider adding it to the language. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 21.09.2010 21:01, Aryeh Gregor wrote: On Mon, Sep 20, 2010 at 2:25 AM, Julian Reschke julian.resc...@gmx.de wrote: 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). This is usually workable in my experience, I agree, and I'd be interested to know of use-cases where it's not close to optimal. i One disadvantage I think the version-in-URI approach has is that it's completely transparent to the HTTP caching system. In particular, it doesn't give caches any information about when a resource is expired. This isn't really an issue if you really know for sure that your resource in question only changes very rarely. However if you have a resource that you would like to cache but where you cannot reliably predict how fast it will change, this might become a problem. If your resource changes too fast, this will clog up caches with dozens of old versions which cannot be deleted because of their long-lived expiry header. (Concrete example: Consider the avatar images of an internet message board. Most users only set their avatar once when they register, though a few may change them based on mood, holidays, etc.) Regards, Philipp Serafin
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 22 Sep 2010, at 22:10, Philipp Serafin wrote: One disadvantage I think the version-in-URI approach has is that it's completely transparent to the HTTP caching system. In particular, it doesn't give caches any information about when a resource is expired. This isn't really an issue if you really know for sure that your resource in question only changes very rarely. However if you have a resource that you would like to cache but where you cannot reliably predict how fast it will change, this might become a problem. If your resource changes too fast, this will clog up caches with dozens of old versions which cannot be deleted because of their long-lived expiry header. (Concrete example: Consider the avatar images of an internet message board. Most users only set their avatar once when they register, though a few may change them based on mood, holidays, etc.) Cached items can be cleared at any time, even if the cache headers indicate that they are still fresh. Browsers and caching proxies already do this. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 628 353 032 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://people.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On Mon, Sep 20, 2010 at 2:25 AM, Julian Reschke julian.resc...@gmx.de wrote: 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). This is usually workable in my experience, I agree, and I'd be interested to know of use-cases where it's not close to optimal. The only advantage I can see offhand to this proposal is that it allows you to convey the info using a header, without modifying the HTML source. This could be useful on sites that cache HTML output heavily. Wikipedia currently uses query strings for version indicators, and while things usually wind up working okay for logged-out users (whose HTML is heavily cached), I'm pretty sure it's mostly because the old version usually still works okay. I'll forward this proposal to a couple of Wikimedia people who would know more and see what they think.
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 19.09.2010 22:33, Robert O'Callahan wrote: ... So for example, page A links to resource B. The browser does a GET on A, and receives a document containing a link to B, and the link element has etags or last-modified attributes. The browser has a cached resource for B, whose etags/last-modified matches the link attribute, so the browser knows its cached B is valid and no further network transactions are required. The linked resource B having the right caching information in the first place (when the browser first fetched it) isn't enough to eliminate the need for an HTTP transaction to validate B later. ... Well, it would if the caching information specifies an expiry time sufficiently in the future. Best regards, Julian
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
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). Best regards, Julian
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On Mon, 20 Sep 2010 08:25:09 +0200, Julian Reschke julian.resc...@gmx.de wrote: 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). Yeah, I was wondering why that was not acceptable here. (Using /script?v=1 etc. where /script?v=x has near-infinite caching.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 20 September 2010 01:40, Roger Hågensen resca...@emsai.net wrote: It would be better to define this as explicitly indicating which resources are NOT valid any longer, with most sites/web applications this would only be a select few links. I like the idea though as it'll allow a page to tell the browser that Oh BTW! If you happen to have this link cached, it was last updated on .. You might wanna re-check that if you got a older copy, despite what the cache copy's expire is. These extra attributes hopefully allow both kinds of validation; both still valid despite being apparently invalid and now invalid, despite being apparently valid. In the first case it functions as a performance optimisation (a conditional-GET request that would result in a 304 is saved), and in the second case it actually prevents a page from rendering using an old resource (that it would not have validated). Some thought need to be given to this though. This will only be same domain right? If not then it could be partly used for a DoS. (if a popular site is compromised and changed to link to a ridiculous amount files on other sites it could get nasty right?) I'm not sure I understand what you're saying, but my first reading suggests that this isn't a problem. These proposed attributes will only cause extra network requests in one case, that of a link to a cached resource which is still valid, but the link contains etags/last-modified which suggests it needs to be validated. Isn't this incredibly minor compared to all the other ways a resource can reference include other pages? - Gavin
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On Sun, Sep 19, 2010 at 11:25 PM, Julian Reschke julian.resc...@gmx.dewrote: 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
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 20.09.2010 17:26, Mike Belshe wrote: ... 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 ... Sorry? That may be a use case that *could* be implemented using LINK, but it's certainly *not* the general use case. For instance, it doesn't seem to be true for any of the currently used link relations in wide use, such as icon or stylesheet (there's no later discovery at all). Or are you referring to using the Link *header* in addition to an equivalent HTML LINK? 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. Link relations cover many other use cases than those that you seem to be considering. For resources that change infrequently but at unexpected times, it's already possible to get what you want by varying the URI when the resource changes (such as putting a timestamp or a revision number into a query parameter). 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. Not sure what you're referring to. If-Modified-Since predates ETags (as far as I recall). 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. My main concern is that if we put etags into *HTML* links, we're leaking protocol-level information into markup. I think it would be good if we could avoid that, and so far I haven't seen any use case that doesn't work without. Best regards, Julian
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
Julian, On 20 September 2010 11:47, Julian Reschke julian.resc...@gmx.de wrote: Or are you referring to using the Link *header* in addition to an equivalent HTML LINK? I think Mike was referring to the Link header. This header is defined in RFC 2068 (but not RFC 2616) in section 19.6.2.4 http://tools.ietf.org/html/rfc2068#section-19.6.2.4 , the most important part of that text is probably that The Link field is semantically equivalent to the LINK element in the HTML. There's also a pending internet draft which expands more fully on this header: https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/ , and that draft in the HTTP case maintains the HTML equivalence (see section 5 of the internet draft). I think the HTML link element is unusual because it does exist both in markup, and at the protocol level. My experimentation with these attributes has been entirely at the protocol, and not the markup level. The standard for the element is in HTML, and so that's why I made my proposal here in whatwg. 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. Link relations cover many other use cases than those that you seem to be considering. For resources that change infrequently but at unexpected times, it's already possible to get what you want by varying the URI when the resource changes (such as putting a timestamp or a revision number into a query parameter). Those approaches work; but require modifying the HTML. So if a server is attempting to have good protocol-level support for the Link header, and to help a client avoid redundant fetches, we're now requiring information leak from the protocol level down to the markup level. I think this problematic, too. If the link element is going to work as both a header and an element, it should have sufficient flexibility to be useful and fully embedded in each application. 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. Not sure what you're referring to. If-Modified-Since predates ETags (as far as I recall). 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. My main concern is that if we put etags into *HTML* links, we're leaking protocol-level information into markup. I think it would be good if we could avoid that, and so far I haven't seen any use case that doesn't work without. I think Mike was speaking about conditional gets generally, which can of course be conditioned on ETag or Last-Modified. Most web browsers, when they have expired cache data, will make a conditional get based on their existing cache entry. If these attributes give a way to avoid this extra request, and if these attributes enhance the protocol-level context, why not support them? - Gavin
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
2010/9/20 Julian Reschke julian.resc...@gmx.de On 20.09.2010 17:26, Mike Belshe wrote: ... 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 ... Sorry? That may be a use case that *could* be implemented using LINK, but it's certainly *not* the general use case. For instance, it doesn't seem to be true for any of the currently used link relations in wide use, such as icon or stylesheet (there's no later discovery at all). Or are you referring to using the Link *header* in addition to an equivalent HTML LINK? Yes, I'm talking about the HTTP header.Sorry for the confusion. 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. Link relations cover many other use cases than those that you seem to be considering. For resources that change infrequently but at unexpected times, it's already possible to get what you want by varying the URI when the resource changes (such as putting a timestamp or a revision number into a query parameter). Yeah, I'm thinking of servers that can learn and auto-generate these headers. I think you're thinking of content authors plunking this into their HTML. The vast majority of HTML is served without consideration of this type of detail. And as the web grows, the content author shouldn't be tied up thinking about them. The servers can do it better anyway. 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. Not sure what you're referring to. If-Modified-Since predates ETags (as far as I recall). 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. My main concern is that if we put etags into *HTML* links, we're leaking protocol-level information into markup. I think it would be good if we could avoid that, and so far I haven't seen any use case that doesn't work without. I don't see anyone realistically doing that either. I'd be perfectly happy to split these out of the HTML-link to the HTTP-link. Maybe its time they be split up. Mike Best regards, Julian
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 20.09.2010 18:17, Gavin Peters (蓋文彼德斯) wrote: I think Mike was referring to the Link header. This header is defined in RFC 2068 (but not RFC 2616) in section 19.6.2.4 http://tools.ietf.org/html/rfc2068#section-19.6.2.4 , the most important part of that text is probably that The Link field is semantically equivalent to the LINK element in the HTML. There's also a pending internet draft which expands more fully on this header: https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/ , and that draft in the HTTP case maintains the HTML equivalence (see section 5 of the internet draft). I happen to be aware of the Link header, and the draft (which, by the way, was approved a few months ago and already is in the RFC Editor's publication queue). I think the HTML link element is unusual because it does exist both in markup, and at the protocol level. My experimentation with these attributes has been entirely at the protocol, and not the markup level. The standard for the element is in HTML, and so that's why I made my proposal here in whatwg. If we're talking about the link header primarily, I'd suggest you move over to the IETF HTTPbis Working Group's mailing list (http://lists.w3.org/Archives/Public/ietf-http-wg/). ... Those approaches work; but require modifying the HTML. So if a server is attempting to have good protocol-level support for the Link header, and to help a client avoid redundant fetches, we're now requiring information leak from the protocol level down to the markup level. I think this problematic, too. If the link element is going to work as both a header and an element, it should have sufficient flexibility to be useful and fully embedded in each application. ... I think Mike was speaking about conditional gets generally, which can of course be conditioned on ETag or Last-Modified. Most web browsers, when they have expired cache data, will make a conditional get based on their existing cache entry. If these attributes give a way to avoid this extra request, and if these attributes enhance the protocol-level context, why not support them? ... The main reason would be additional complexity (IMHO). But if we're talking about HTTP this mailing list most certainly is not the right place to discuss this. Later on Mike writes: Yeah, I'm thinking of servers that can learn and auto-generate these headers. I think you're thinking of content authors plunking this into their HTML. So, clarifying: you would send an *additional* Link header for the stylesheet relation, and augment it with the current etag? I'd be perfectly happy to split these out of the HTML-link to the HTTP-link. Maybe its time they be split up. I think both should be consistent (like relation type names mean the same thing); but that doesn't necessarily mean that their feature sets need to be identical. Best regards, Julian
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote: 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. ... Clarifying: essentially that's a workaround for resources for which the actual cache information returned by HTTP GET isn't accurate, right? Which of course leads to the question: if the maintainers of a site can't get their cache information right, what makes you think they can get their HTML right instead? Best regards, Julian
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
2010/9/19 Julian Reschke julian.resc...@gmx.de On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote: 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. ... Clarifying: essentially that's a workaround for resources for which the actual cache information returned by HTTP GET isn't accurate, right? Which of course leads to the question: if the maintainers of a site can't get their cache information right, what makes you think they can get their HTML right instead? No, it's a performance optimization. I presume that if the link attributes indicate that the browser's cached resource is valid, the browser does not issue a network request to validate the resource. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 19.09.2010 20:47, Robert O'Callahan wrote: 2010/9/19 Julian Reschke julian.resc...@gmx.de mailto:julian.resc...@gmx.de On 15.09.2010 19:45, Gavin Peters (蓋文彼德斯) wrote: 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. ... Clarifying: essentially that's a workaround for resources for which the actual cache information returned by HTTP GET isn't accurate, right? Which of course leads to the question: if the maintainers of a site can't get their cache information right, what makes you think they can get their HTML right instead? No, it's a performance optimization. I presume that if the link attributes indicate that the browser's cached resource is valid, the browser does not issue a network request to validate the resource. :-) So it's a workaround that causes a performance optimization. It wouldn't be necessary if the linked resource would have the right caching information in the first place. So again: what makes you think they can get their HTML right instead? Best regards, Julian
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
2010/9/19 Julian Reschke julian.resc...@gmx.de So it's a workaround that causes a performance optimization. It wouldn't be necessary if the linked resource would have the right caching information in the first place I think you're misunderstanding the proposal. 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. So for example, page A links to resource B. The browser does a GET on A, and receives a document containing a link to B, and the link element has etags or last-modified attributes. The browser has a cached resource for B, whose etags/last-modified matches the link attribute, so the browser knows its cached B is valid and no further network transactions are required. The linked resource B having the right caching information in the first place (when the browser first fetched it) isn't enough to eliminate the need for an HTTP transaction to validate B later. Rob
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
2010/9/19 Julian Reschke julian.resc...@gmx.de: So it's a workaround that causes a performance optimization. It wouldn't be necessary if the linked resource would have the right caching information in the first place. 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.
Re: [whatwg] Proposal: add attributes etags last-modified to link element.
On 2010-09-20 02:37, Aryeh Gregor wrote: 2010/9/19 Julian Reschkejulian.resc...@gmx.de: So it's a workaround that causes a performance optimization. It wouldn't be necessary if the linked resource would have the right caching information in the first place. 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. Describing it that way sounds odd, as that would be explicitly indicating which resources are still valid, imagine the bloat if the document links to hundreds of others. It would be better to define this as explicitly indicating which resources are NOT valid any longer, with most sites/web applications this would only be a select few links. I like the idea though as it'll allow a page to tell the browser that Oh BTW! If you happen to have this link cached, it was last updated on .. You might wanna re-check that if you got a older copy, despite what the cache copy's expire is. Some thought need to be given to this though. This will only be same domain right? If not then it could be partly used for a DoS. (if a popular site is compromised and changed to link to a ridiculous amount files on other sites it could get nasty right?) -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
[whatwg] Proposal: add attributes etags last-modified to link element.
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!)
