W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [CSP] Clarifications regarding the HTTP LINK Header

From: Brian Smith <brian@briansmith.org>
Date: Tue, 11 Nov 2014 15:56:31 -0800
Message-ID: <CAFewVt7o8LXQA6ySgAxcniAKkBdKaBwC0mtUTwXjW8JD5_dQWg@mail.gmail.com>
To: Ilya Grigorik <igrigorik@gmail.com>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Nov 11, 2014 at 2:46 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:
>> I also noticed an interesting study of support for the HTTP LINK
>> header for rel=stylesheet [1]. It indicates that Firefox and old
>> versions of Opera are the only major browsers that support the HTTP
>> LINK header for rel=stylesheet. Perhaps it is a good idea to drop the
>> HTTP LINK header with rel=stylesheet from HTML? This would be a good
>> time to decide, because Blink is considering adding support now [2].
> There are legitimate use cases for Link, we should not drop support.
> Resource-Hints (rel=preload in particular) is relying on Link to allow
> servers+proxies to emit resource hints without modifying the response body.
> This is an important use case for CDN's / FEO products / BW-reduction
> proxies (Opera, Chrome, etc).

My question was not whether we should drop support for any/all Link
relations. My question was specifically about dropping support for the
HTTP LINK header with rel=stylesheet.

> http://w3c.github.io/resource-hints/#developer-server-and-proxy-generated-hints-preload
> It would be good to clarify in the spec how CSP header interacts with Link.

I agree. And, in particular, it would be good to call out what is to
happen when <meta http-equiv=Content-Security-Policy> is used with
Link rel=preload and how it affects any/all other prefetching,
especially preloading done as part of the prescanner.

Received on Tuesday, 11 November 2014 23:56:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC