Bug 20018 - Linking to style sheets with HTTP headers is not implemented in WebKit
Summary: Linking to style sheets with HTTP headers is not implemented in WebKit
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://simon.html5.org/test/ie7b2-bug...
Keywords:
Depends on: 51940
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-12 10:50 PDT by Gérard Talbot (no longer involved)
Modified: 2023-09-28 08:53 PDT (History)
16 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gérard Talbot (no longer involved) 2008-07-12 10:50:57 PDT
"
Web server managers may find it convenient to configure a server so that a style sheet will be applied to a group of pages. The HTTP Link header has the same effect as a LINK element with the same attributes and values.
"
HTML 4.01, section 14.6 Linking to style sheets with HTTP headers
http://www.w3.org/TR/html4/present/styles.html#h-14.6

Steps to reproduce
------------------
Load provided URL

Actual results in Safari 3.1.2 build 525.21
-------------------------------------------
The webpage has a red background.

Expected results
----------------
The webpage should have a green background.

Notes
- Link http-equiv
<meta http-equiv=Link content="&lt;support/limepage.css>; rel=stylesheet">
http://simon.html5.org/test/ie7b2-bugs/030.html 
also fails
- meta-testcase for various methods of linking and/or importing CSS stylesheets
http://www.hixie.ch/tests/adhoc/css/cascade/import/002.html
fails, in particular for (a) to (f) when the HTTP response headers
{
Link:	<002d.css>; rel="stylesheet"	
Link:	<002f.css>; rel="stylesheet"
}
are listed:
View HTTP Response Header for that meta-testcase:
http://web-sniffer.net/?url=http%3A%2F%2Fwww.hixie.ch%2Ftests%2Fadhoc%2Fcss%2Fcascade%2Fimport%2F002.html&submit=Submit&http=1.1&gzip=yes&type=GET&uak=0
Comment 1 Gérard Talbot (no longer involved) 2008-07-12 11:49:53 PDT
Safari 4.0 build 526.11 also fails all 3 tests.
Firefox 3.0, Opera 9.51 both pass all 3 tests.

I searched for a duplicate and did not find one.
Comment 2 Robert Blaut 2008-07-15 03:31:41 PDT
Confirmed bug. Webkit is the only common engine despite MS IE which doesn't have HTTP Link header implemented: http://ietfreport.isoc.org/idref/draft-nottingham-http-link-header/ Gecko and Opera's Presto have it implemented long time ago.
Comment 3 Mathias Bynens 2010-09-13 06:36:25 PDT
Here’s the matching Chromium bug ticket which should be updated when this is resolved: http://code.google.com/p/chromium/issues/detail?id=19237
Comment 4 Alexey Proskuryakov 2010-09-13 09:57:02 PDT
This looks like a harmful feature to me - and given that IE doesn't implement it, we probably don't have to either. Anything that takes additional server configuration and makes a pages dysfunctional when opened from file:/// adds confusion. And there doesn't seem to be any benefit.

Note this language from HTML4: "This section only applies to user agents conforming to versions of HTTP that define a Link header field. Note that HTTP 1.1 as defined by [RFC2616] does not include a Link header field (refer to section 19.6.3)." HTML5 doesn't mention the link header field, as far as I can tell.
Comment 5 Mathias Bynens 2010-09-13 10:08:26 PDT
(In reply to comment #4)
> HTML5 doesn't mention the link header field, as far as I can tell.

HTML5 mentions the Link header field here: http://www.w3.org/TR/html5/semantics.html Quote:

> Some versions of HTTP defined a Link: header, to be processed like a series of link elements. If supported, for the purposes of ordering links defined by HTTP headers must be assumed to come before any links in the document, in the order that they were given in the HTTP entity header. (URIs in these headers are to be processed and resolved according to the rules given in HTTP; the rules of this specification don't apply.)
Comment 6 Anne van Kesteren 2010-09-19 03:18:28 PDT
http://tools.ietf.org/html/draft-nottingham-http-link-header defines it. (Almost RFC.)
Comment 7 sideshowbarker 2010-12-14 10:25:46 PST
(In reply to comment #6)
> http://tools.ietf.org/html/draft-nottingham-http-link-header defines it. (Almost RFC.)

Now RFC 5988: http://tools.ietf.org/html/rfc5988
Comment 8 Alexey Proskuryakov 2010-12-14 12:37:55 PST
Still looks like a harmful feature. Hopefully, IE wont implement, and we won't need to, either.
Comment 9 Gavin Peters 2010-12-14 12:43:41 PST
I have a patch I'm working on for this.  I haven't through through ap's style-sheet objections very carefully, but my intention is to first just have Link: rel=prefetch work in HTTP headers.
Comment 10 Mathias Bynens 2010-12-14 13:19:57 PST
(In reply to comment #8)
> Still looks like a harmful feature. Hopefully, IE wont implement, and we won't need to, either.

Could you clarify why this would be harmful?

In comment #4 you say there doesn’t seem to be any benefit, but the benefits are huge. Adding support for the Link header (not only supporting rel=stylesheet but also all other valid link relations) would be very useful. Imagine being able to add a stylesheet to a bunch of unstyled static HTML documents without modifying them all.

Full Link header support would also make it possible to have feed-autodiscovery on non-HTML pages (like images, audio, video, plain text files, etc).
Comment 11 Alexey Proskuryakov 2010-12-14 13:57:58 PST
Both server operators and people looking at Web content from client side will have more special cases to check, maintain and worry about. Intermediate software like proxies will have more opportunities to handle the content wrong. The end result will be an even less reliable Web.

Having multiple ways to do the same thing has a considerable cost, and isn't always better than having one way.

Most importantly, the experience with other document specific information being passed in HTTP headers (like charset or Vary) has been so miserable that adding more out of band information gets extremely unwelcome.

Note that this doesn't fully apply to feed-autodiscovery or prefetch, and those shouldn't be discussed here. This bug is very specifically about rel=stylesheet.
Comment 12 Gavin Peters 2010-12-14 14:10:10 PST
Mathias,

My soon-to-be-shown-patch factors out a lot of the LinkLoader logic into the loader directory, and then it's just a matter of connecting the HTML element or the header parser in.  Alexey's right though; perhaps another bug for the Link header period is in order, I'll create that.
Comment 13 Gavin Peters 2011-01-13 11:32:20 PST
See bug 51940 for some implementation of Link headers.
Comment 14 Mathias Bynens 2011-05-16 00:41:31 PDT
Test cases: http://greenbytes.de/tech/tc/httplink/
Comment 15 Brady Eidson 2012-02-19 22:14:56 PST
http://mathiasbynens.be/notes/css-without-html
Comment 16 Ahmad Saleem 2023-09-27 15:09:49 PDT
Seems like only Firefox Nightly is passing tests mentioned in Comment 14.

Safari 17 and Chrome Canary 119 are same.

CCing - @Anne, @Simon and @Alexey - for their input and whether we should have it on 'RADAR'.
Comment 17 Anne van Kesteren 2023-09-28 08:53:13 PDT
This is tracked by https://github.com/whatwg/html/issues/8741 and I agree with Chromium that I don't think we should add this to the web (for stylesheets in particular).