- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 16 Dec 2014 13:00:10 +0100
- 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