Re: [fetch] Update Fetch with shiny, new CSP hooks (#140)

> @@ -2087,6 +2094,11 @@ <h4 id="should-response-to-request-be-blocked-due-to-nosniff?"><dfn title="shoul
>       "<code title>manual</code>" and <var title>response</var>'s
>       <span title=concept-response-type>type</span> is "<code title>opaqueredirect</code>".
>      </ul>
> +
> +   <li>
> +     <p>Execute <a href=https://w3c.github.io/webappsec-csp/set-response-policy-list>Set
> +     <var title>response</var>'s policy list</a> on <var title>response</var>.
> +     <span data-anolis-ref>CSP</span>

> You can't get to the header list of an opaque response (it will always be empty).

I see. As you note, responses which came from the network will be covered by the HTTP-network fetch hook, so the responses we need to deal with are opaque responses which are synthetically constructed by the SW.

Would it be appropriate for this hook to address the `internal response`'s header list? That seems like the most straightforward way to handle things.

> On top of that, should we avoid setting a policy list here if the response already has one?

Probably. I'm not sure whether that's the right thing to do, though. I think I'm going to want to read the policy information as early as possible in fetch when grabbing things from the network (for `Set-Cookie` if no other reason). It's not clear that I can avoid setting the policy twice if I want to do that, and handle synthetic responses coming from the service worker.

I think what might work is for the `set the CSP list` algorithm to clear the response's CSP list, and overwrite it with whatever the response's header list (or it's internal response's header list) contains. WDYT?

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/140/files#r41877283