Re: [whatwg/fetch] CH processing, cross-origin redirects and service workers (#800)

> I posted my thoughts here: https://freenode.logbot.info/whatwg/20180824#c1678383. TL;DR is that the extending-SOP-exceptions concern can probably be ignored for now, though we should add tests to ensure values are adequately validated and preflighted as appropriate.

Thanks. Restricting the values SGTM.

> Another concern not mentioned here is that we need to deal with the case where these headers were already set by the developer. If a developer sets DPR a browser would end up appending to it with the current wording. Is that desired? I'd argue it's better to avoid that and only set the header if it's not already set. (We need tests for this too.)

That makes sense. I can add that to https://github.com/whatwg/fetch/pull/773

> For the concerns mentioned in OP, it sounds like setting the headers early and potentially removing them upon redirects, even if they were developer-set, is the away to go.

OK, so a tentative design which may work can look something like:
* Perform cross-origin/Feature-Policy checks at step 1.7 of [fetch](https://fetch.spec.whatwg.org/#concept-fetch), before adding any hints
* Perform cross-origin/Feature-Policy checks again in [http redirect fetch](https://fetch.spec.whatwg.org/#concept-http-redirect-fetch) and remove any of the hint headers there, if they shouldn't be sent.

That would indeed have the side effect of removing user-added CH headers from cross-origin redirects (unless they were opted-in using Feature-Policy). I think that's an edge case which we can live with.

@annevk - does that make sense?












-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/800#issuecomment-416135062