Julian,<div><br></div><div><div class="gmail_quote">On 20 September 2010 11:47, Julian Reschke <span dir="ltr"><<a href="mailto:julian.reschke@gmx.de" target="_blank">julian.reschke@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or are you referring to using the Link *header* in addition to an equivalent HTML <LINK>?<div><br></div></blockquote><div><br></div><div>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 <a href="http://tools.ietf.org/html/rfc2068#section-19.6.2.4" target="_blank">http://tools.ietf.org/html/rfc2068#section-19.6.2.4</a> , 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: <a href="https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/" target="_blank">https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/</a> , and that draft in the HTTP case maintains the HTML equivalence (see section 5 of the internet draft).</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
existing cache control mechanics, so if the browser does have the<br>
resource in cache but it needs validation, you didn't accomplish what<br>
you had hoped with the LINK header - the client is still going to make a<br>
costly round-trip. For savvy content authers, they could, as you<br>
suggest, simply modify the content to work with this case. This<br>
effectively restricts the full benefit of LINK to the subset of<br>
resources which are static and have long-lived expiry. That would leave<br>
LINK less useful to large swaths of the internet where they do leverage<br>
if-modified-since and etags.<br>
</blockquote>
<br></div>
Link relations cover many other use cases than those that you seem to be considering.<br>
<br>
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).</blockquote>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rather than ask this question about the LINK header attributes, you<br>
could instead aim your question at HTTP - why does HTTP bother with<br>
if-modified-since? But the answer is moot - that decision was made<br>
long ago.<br>
</blockquote>
<br></div>
Not sure what you're referring to. If-Modified-Since predates ETags (as far as I recall).</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Given that the web *does* use these basic cache control mechanisms, why<br>
*wouldn't* you want the LINK header to be capable of using them too?<br>
:-) This proposal is actually just making LINK more like the rest of<br>
HTTP.<br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br></div><div>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?</div>
<div><br></div><div>- Gavin</div></div></div>