search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.19k stars 2.71k forks source link

"create navigation params by fetching" invokes "should navigation request of type be blocked by Content Security Policy?" without setting the policy container #10796

Open mbrodesser-Igalia opened 6 days ago

mbrodesser-Igalia commented 6 days ago

What is the issue with the HTML Standard?

The request's policy container is set only in ^1, step 12. "should navigation request of type be blocked by Content Security Policy?" is called from ^2, step 19.3. ^1 is called from step 19.5 of ^2. So during the first iteration of the while-loop at step 19 of ^2, the request's policy container will be its default value, "client". ^3 doesn't handle "client", though.

CC @antosart, as mentioned at https://github.com/w3c/webappsec-csp/pull/692#issuecomment-2500047541.

domenic commented 5 days ago

@annevk, I think you might be best-positioned to help solve this? In particular, I'm unsure how to leave the resolution of "client" in Fetch, while still letting HTML do the manual redirect-following that it does.

annevk commented 5 days ago

Since HTML has the need to create new environments as it encounters new URLs, the environment should be controllable by HTML and cannot just be cloned as a one-off and count for all subsequent fetches.

Note that when we follow the redirect https://fetch.spec.whatwg.org/#http-redirect-fetch is invoked which invokes "main fetch" which doesn't even attempt to update the environment.

I'm not sure what the best way to rejigger this is. Perhaps the client/environment should be owned by the fetch controller so it can be accessed by HTML.

(It also strikes me that there's probably multiple environments in play. One that caused the navigation (e.g., responsible for referrer) and one that is responsible for the URL we are navigating to at the moment (e.g., responsible for service workers).)