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

Re: MIX: Exiting last call?

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 16 Dec 2014 13:00:10 +0100
Message-ID: <CADnb78j0+KuKPyCg2WxzKj2E+e0Yy97GH22EOko7KoaXY_ytMA@mail.gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>
Cc: Mike West <mkwst@google.com>, Brian Smith <brian@briansmith.org>, Michael Cooper <cooper@w3.org>, David Walp <David.Walp@microsoft.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Mon, Dec 15, 2014 at 7:58 PM, Daniel Veditz <dveditz@mozilla.com> wrote:
> HSTS is strictly a feature of HTTP headers; I'm not sure it makes
> logical sense to apply it before knowing you have an HTTP(s) origin. In
> practice I don't see Mozilla hoisting that logic out of the HTTP
> protocol handler to a higher level as implied in the Fetch spec.

I'm not sure I understand this comment. HSTS is an HTTP header but it
instructs how further fetches to a certain URL space have to be made.
Therefore it has to be applied at some point before fetching the
resource, no?


> In addition there is apparently a logic layer above Fetch because Fetch
> only handles data:, about:, http: and https: urls -- everything else
> gives a network error. Whatever layer handles all the other possible
> protocols (ftp, mailto, feed, etc) is the one that CSP needs to run at,
> not step 4 in the middle of Fetch.

Fetch handles all schemes. mailto and feed currently result in a
network error in this context though. Only in the context of
navigation (which might be the higher-level you're thinking of?) might
they trigger some other effect.

And if CSP would only run in the context of navigation it would not
handle subresources well, so it definitely needs to be here.


-- 
https://annevankesteren.nl/
Received on Tuesday, 16 December 2014 12:00:38 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC