<br><br><div class="gmail_quote">2010/9/20 Julian Reschke <span dir="ltr"><<a href="mailto:julian.reschke@gmx.de">julian.reschke@gmx.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On 20.09.2010 17:26, Mike Belshe wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<div class="im"><br>
LINK, in general, allows a server to indicate to a client that it will<br>
need a particular resource earlier than the client otherwise would have<br>
discovered it.  Today, the LINK header doesn't assist with understanding<br>
</div></blockquote>
> ...<br>
<br>
Sorry?<br>
<br>
That may be a use case that *could* be implemented using LINK, but it's certainly *not* the general use case.<br>
<br>
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).<br>
<br>
Or are you referring to using the Link *header* in addition to an equivalent HTML <LINK>?</blockquote><div><br></div><div>Yes, I'm talking about the HTTP header.    Sorry for the confusion.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
<br>
<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>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.</div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
 </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<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).<div class="im"><br>
<br>
<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 don't see anyone realistically doing that either.</div><div><br></div><div>I'd be perfectly happy to split these out of the HTML-link to the HTTP-link.  Maybe its time they be split up.</div>
<div><br></div><div>Mike</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Best regards, Julian<br>
</blockquote></div><br>