[whatwg/fetch] consider adding note that CORS preflight check excludes headers added by the browser or extensions (#1005)

The CORS protocol currently requires sending a preflight request if there is an unsafe header on the request.  Step 4.1 here:

https://fetch.spec.whatwg.org/#http-fetch

However, in practice browsers only examine headers set by content for this check.  They exclude headers set by the browser itself or extensions.

For example, in firefox the CORS implementation looks at a header list:

https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/netwerk/protocol/http/nsCORSListenerProxy.cpp#983

Set explicitly in the child process close to the content script:

https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/dom/fetch/FetchDriver.cpp#673
https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/dom/xhr/XMLHttpRequestMainThread.cpp#2657

Until recently chromium also worked the same way by virtue of performing its entire CORS operation in the renderer process close to content.

Chromium recently implemented an out-of-renderer CORS (OOR-CORS) feature that moves the CORS operation into the network stack.  This caused the preflight logic to begin examining headers set by browser internals and extensions.  This has caused a great deal of web compat problems for the OOR-CORS rollout.  There has been hesitance to match the old behavior because the spec does not allow it.

I am unsure what webkit does here.

Given the firefox behavior and legacy chromium behavior would it be reasonable to add a non-normative note indicating headers set by browser internals and extensions are excluded from the CORS preflight check?

-- 
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/1005