New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 58456 link

Starred by 64 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jan 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocked on:
issue 455648

Blocking:
issue 19237



Sign in to add a comment

Link HTTP header

Project Member Reported by gavinp@chromium.org, Oct 8 2010

Issue description

The Link HTML element has a response header equivalent.  It follows the form:

Link: <http://href.here/to/resource.html>;rel="prefetch"

we should support this header, specifically for rel types prefetch, subresource & dns-prefetch.

- Gavin
 

Comment 1 by gavinp@chromium.org, Oct 11 2010

 Issue 30690  has been merged into this issue.
The Link header field is now defined by RFC 5988:

http://tools.ietf.org/html/rfc5988

see also https://bugs.webkit.org/show_bug.cgi?id=20018
Project Member

Comment 4 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network

Comment 5 by math...@qiwi.be, May 8 2013

Note that support for the Link HTTP header will have to be implemented in Blink, else it would break backwards compatibility for Opera users. Opera has supported the Link HTTP header since 2005.

Comment 6 by tonyg@chromium.org, May 2 2014

Cc: igrigo...@chromium.org piatek@chromium.org
 Issue 120104  has been merged into this issue.

Comment 7 by tonyg@chromium.org, May 2 2014

Cc: simonhatch@chromium.org oysteine@chromium.org gavinp@chromium.org
Labels: -Type-Bug Type-Feature
Owner: ----
Status: Available
Hey Gavin, there's some renewed interest around this and given the age of the bug I'm marking available. Please pick it up again if it's actively in your queue.

Comment 9 by apb...@gmail.com, May 2 2014

Glad to see this is being given attention, I want to be able to cut down on
my HTTP body as much as I can.
Blocking: chromium:370696

Comment 11 by tonyg@chromium.org, Jul 12 2014

Cc: zh...@chromium.org

Comment 12 by tonyg@chromium.org, Jul 12 2014

Blocking: chromium:19237
Cc: kenjibaheux@chromium.org
Support for LINK response headers has several important use cases for better web performance:

1. Loading stylesheets early is important, but in some cases the time for the backend server to stitch together the HTML that contains the LINK HTML tag can take a fair amount of time. Also, some CMSs don't flush ANY markup until the entire HTML document is complete. In both of these situations, the server could return a LINK: rel=stylesheet response header immediately which would allow the browser to fetch it early so the page would render faster.

2. Intermediaries (proxies, CDNs) could observe this header and proactively fetch resources to their intermediate cache so that it's ready when the browser later requests it.

3. The Resource Hints proposal ( http://w3c.github.io/resource-hints/ ) includes rel=preload. The best way to send a LINK rel=preload hint is as a HTTP response header - this gets it to the browser sooner than the alternative of including it in markup.


I have performed a test on my own site to determine Firefox’s behavior when a style sheet is (additionally) linked in the Link header of the web page.

Without the Link header: The request for the style sheet is initiated after the HTML has finished loading. Full results: http://www.webpagetest.org/result/141117_VJ_YTY/

With the Link header: the request for the style sheet is initiated soon after the HTML has started loading. Full results: http://www.webpagetest.org/result/141117_JQ_101R/

See the attached image for a direct comparison of the waterfall charts. It is evident that the style sheet request is initiated sooner using the Link header in Firefox, which could, on more complex websites, result in noticeable page render/load improvements.
B2qEhUVIUAApypA.png large.png
462 KB View Download
Checking that particular site, it looks like both Chrome [1] and FF [2] pick a suboptimal strategy: they queue up the stylesheet fetch request on the same connection as the HTML request (see connection view)... which is why the fetch is initiated immediately after the HTML response is finished. By contrast, IE dispatches it on a different connection [3], and gets it sooner.

I'm 100% for supporting Link, but above example is probably more of an illustration of opportunities to optimize the scheduling decisions in FF/Chrome. Either that.. or move everyone to SPDY / HTTP/2 to avoid the whole head-of-line blocking issue with HTTP/1.1! :)

[1] http://www.webpagetest.org/result/141118_G8_32159a8560f2a93380b56fffae76683d/3/details/
[2] http://www.webpagetest.org/result/141117_VJ_YTY/4/details/
[3] http://www.webpagetest.org/result/141118_36_1433d697091acb5716743ad7ffd8d1f5/1/details/

Comment 17 by y...@yoav.ws, Nov 24 2014

Cc: y...@yoav.ws
I started playing around with an experimental implementation (just for kicks. had some spare time on the train). 

A few notes:
* It seems like at the time that the Link headers are received in Blink (in ResourceFetcher::didReceiveResponse), the document is not yet created. The document seems to be created only after DocumentLoader::dataReceived is run.
* Having the document around seems critical for anything beyond DNS prefetching & possibly preconnecting.

Does anyone have a clear idea if the Link headers can be caught further down the line, when the document is already alive?

I also wonder what would be a better implementation strategy: having the Link headers create <link> elements that are not part of the DOM, but kept around as long as the document is alive, or simply implement the various Link features (DNS prefetch, preconnect, preload, prerender) separately. The latter path would probably not enable CSS support (or at least would make it harder), but I'm not sure there's a clear use-case for that.
"The latter path would probably not enable CSS support (or at least would make it harder), but I'm not sure there's a clear use-case for that."

Note that in Mozilla, it also enables XSLT support.

Comment 19 by y...@yoav.ws, Dec 17 2014

I've uploaded an initial CL (not yet ready for review) for dns-prefetch support which looks into Link after CSP is applied
Project Member

Comment 20 by bugdroid1@chromium.org, Feb 2 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=189352

------------------------------------------------------------------
r189352 | yoav@yoav.ws | 2015-02-02T18:25:27.495253Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader?r1=189352&r2=189351&pathrev=189352
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/core.gypi?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeader.h?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-empty-expected.txt?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-in-url-expected.txt?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-invalid-expected.txt?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-valid-expected.txt?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-empty.php?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-in-url.php?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-invalid.php?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-valid.php?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeader.cpp?r1=189352&r2=189351&pathrev=189352
   A http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeaderTest.cpp?r1=189352&r2=189351&pathrev=189352

Add a parser for Link headers

This CL adds a parser for Link headers, that would enable to support them for various features that can benefit from such support. Resource Hints (and the non-standard hints: dns-prefetch, prefetch, etc) are likely to be the first users.

BUG= 58456 

Review URL: https://codereview.chromium.org/889883002
-----------------------------------------------------------------
Project Member

Comment 21 by bugdroid1@chromium.org, Feb 3 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=189420

------------------------------------------------------------------
r189420 | perezju@chromium.org | 2015-02-03T15:05:31.082706Z

Changed paths:
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-in-url.php?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-invalid.php?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-valid.php?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeader.cpp?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeaderTest.cpp?r1=189420&r2=189419&pathrev=189420
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/core.gypi?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeader.h?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-empty-expected.txt?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-in-url-expected.txt?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-invalid-expected.txt?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-valid-expected.txt?r1=189420&r2=189419&pathrev=189420
   D http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-empty.php?r1=189420&r2=189419&pathrev=189420

Revert of Add a parser for Link headers (patchset #8 id:140001 of https://codereview.chromium.org/889883002/)

Reason for revert:
A memory leak was detected by the asan tool.

Original issue's description:
> Add a parser for Link headers
> 
> This CL adds a parser for Link headers, that would enable to support them for various features that can benefit from such support. Resource Hints (and the non-standard hints: dns-prefetch, prefetch, etc) are likely to be the first users.
> 
> BUG= 58456 
> 
> Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=189352

TBR=pmeenan@google.com,mkwst@chromium.org,yoav@yoav.ws
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 58456 

Review URL: https://codereview.chromium.org/876633009
-----------------------------------------------------------------
Project Member

Comment 22 by bugdroid1@chromium.org, Feb 4 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=189477

------------------------------------------------------------------
r189477 | yoav@yoav.ws | 2015-02-04T10:47:41.045722Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/core.gypi?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeader.h?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-empty-expected.txt?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-in-url-expected.txt?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-invalid-expected.txt?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-valid-expected.txt?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-empty.php?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-in-url.php?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-space-invalid.php?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/linkHeader/link-header-no-crash-valid.php?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeader.cpp?r1=189477&r2=189476&pathrev=189477
   A http://src.chromium.org/viewvc/blink/trunk/Source/core/loader/LinkHeaderTest.cpp?r1=189477&r2=189476&pathrev=189477

Add a Link header parser.

This CL adds a parser for Link headers,
that would enable to support them for various features that can benefit from such support.
Resource Hints (and the non-standard hints: dns-prefetch, prefetch, etc) are likely to be the first users.

This is a re-submit of 889883002 which got reverted.

BUG= 58456 

Review URL: https://codereview.chromium.org/889413005
-----------------------------------------------------------------

Comment 23 by y...@yoav.ws, Feb 5 2015

Blockedon: chromium:455648
Project Member

Comment 24 by bugdroid1@chromium.org, Feb 10 2015

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=189875

------------------------------------------------------------------
r189875 | yoav@yoav.ws | 2015-02-10T07:08:49.185367Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/RuntimeEnabledFeatures.in?r1=189875&r2=189874&pathrev=189875

Change Link header feature flag to experimental

BUG= 58456 

Review URL: https://codereview.chromium.org/908863005
-----------------------------------------------------------------
Blocking: -chromium:370696
Another advantage of the Link header is that as being a header, in HTTP/2 it can be compressed and referenced cheaply by additional requests.

With the growing size of non-essential Link tags for things like caching, background colors of user agent toolbars, favicons and their mask/color; this could improve performance.

I share the concern from issue 19237 and https://bugs.webkit.org/show_bug.cgi?id=20018#c11 that we may not want to encourage use of Link for stylesheets. But it may make sense to support it nonetheless for consistency. Good conventions and time will learn whether it is wise to use it for that purpose.
Labels: fixit-net
Labels: -Cr-Internals -Cr-Internals-Network -fixit-net Cr-Blink-Loader
Status: Archived
Don't think this is a good net fixit issue - the code for this lives well outside of the network stack, in the renderer process.
Status: Available
(not clear why status was set to archived)

Comment 30 by zh...@chromium.org, Jan 26 2016

Cc: -zh...@chromium.org

Comment 31 by y...@yoav.ws, Jan 26 2016

Owner: y...@yoav.ws
Status: Fixed
Support for link headers have landed, for dns-prefetch, preconnect and preload rels.

Support for more headers can be added as well, but I'd say we can mark this issue as fixed, as link header support was shipped a while ago: https://codereview.chromium.org/1245083002

Comment 32 by ise...@gmail.com, May 31 2016

The Link header in combination with CSS enables styling of non-HTML pages like images. This enables you to do centering, titles, attribution, etc. on directly linked image and video files. I used to do this back when Opera was pre-Blink, and Firefox has also supported this for quite a while.
What about stylesheet rel?

Comment 34 by y...@yoav.ws, Jan 19 2017

Not currently supported. Do you have a specific use case for that?

Comment 35 by ise...@gmail.com, Jan 20 2017

@34: Styling direct image links like used to be possible in Firefox and Opera.

Comment 36 by y...@yoav.ws, Jan 20 2017

isephr - can you file a separate issue for that detailing the use case for it?

Also, did Firefox drop support for that? If so, what was their reasoning?
Just made an attempt at a bug report / feature request for rel stylesheet issue here https://bugs.chromium.org/p/chromium/issues/detail?id=692359


Sign in to add a comment