- From: Mike Belshe <mike@belshe.com>
- Date: Mon, 20 Sep 2010 09:18:32 -0700
2010/9/20 Julian Reschke <julian.reschke at 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100920/4bb3fab7/attachment.htm>
Received on Monday, 20 September 2010 09:18:32 UTC