|Summary:||implement Link: header|
|Product:||WebKit||Reporter:||Gavin Peters <gavinp>|
|Severity:||Normal||CC:||abarth, ap, front.end.developing, gavinp, jerome, mathias, me, miket, mike, nickshanks|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
|Bug Depends on:||102936, 51941, 57842|
Description Gavin Peters 2011-01-05 11:43:52 PST
RFC 5988 re-introduces the Link: header, last seen in RFC 2068 (and not RFC 2616!). The Link header has lots of uses; one less-confusing such use is to use it for rel=prefetch, and rel=subresource allowing server side indication of important resources in advance of a document parse. Implement the link header.
Comment 1 Alexey Proskuryakov 2011-01-07 12:27:04 PST
I'm wondering what the difference between link=prefetch and link=subresource is. I couldn't find the latter documented anywhere. Is this the same as prefetch, but delaying load event?
Comment 2 Adam Barth 2011-01-07 12:32:55 PST
> I'm wondering what the difference between link=prefetch and link=subresource is. I couldn't find the latter documented anywhere. I believe prefetch is a low priority load (so it waits until all the other resources for the page are loaded before clogging up the network) whereas subresource is a high priority load that tries to load the resource in time before its needed by the same page.
Comment 3 Gavin Peters 2011-01-13 11:45:05 PST
To be clear about my first comment, I think the initial implementation of the Link header should shy away from rel types that mutate or affect data; so let's stick with rel=prefetch, rel=subresource, rel=dns-prefetch and possibly rel=icon.
Comment 5 Pinal 2014-11-24 00:26:48 PST
What is the state of this bug? We have implemented Link header for mobile and I was disappoint why nobody implement it well.