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

I agree with @wanderview that this seems orthogonal. If anything, the closest similarity I can think to is the discussion about "internal" redirects in #576.

In that case, similar to here, browser implementation details can lead to inconsistent web-observable behaviours (in that case, the distinction of "internal" redirects; in this case, the distinction of internally-added headers)

Regardless of the spec purity angle (that is, that we can only spec behaviours for things that conform to specced behaviours), there does seem to be a set of implementation decisions that can either lead to web-observable behaviours or browser-interop/compat issues. When last looking at #869 (and the related Chrome bug), one of the challenges was trying to decide whether or not [locally configured policy](https://cloud.google.com/docs/chrome-enterprise/policies/?policy=AutoSelectCertificateForUrls) should be able to alter the CORS-preflight. An argument for compat (largely with Google's own internal servers, which I find a poor reason) would suggest the policy can/should affect preflights, while alignment to the resolution in #869 would suggest that it should not. Aligning with #869 would at least ensure Firefox could be used at Google, while if Chrome went its own way, I am confident it would make Firefox less likely to be able to used to access internal sites, and thus less likely to be used to test external sites.

Ultimately, while browsers all ideally try to align on the same spec, and specs are signs, not cops, there's also benefit in having some description for the "common" extensibility points or internal implementation decisions UAs have to make, and how and whether these are web-observable or not. My pragmatic view is that it's worth documenting these cases, because the more we leave them up in the air without clear guidance, the more we'll have organizations and developers coding to specific implementation-extension points, and that's worse for browser agility and interoperability.

If Edge and Chromium and Firefox all support a common extension API, but that API behaves differently in different UAs, then organizations that adopt/mandate the extension may preclude certain UAs based on their behaviours. Having seen that happen in Google, leading to less testing in other UAs, I'd like to avoid that.

Without wanting to put words in @youennf's mouth, that also seems aligned with the response in https://github.com/whatwg/fetch/issues/1005#issuecomment-596596965

-- 
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#issuecomment-597224101

Received on Tuesday, 10 March 2020 17:49:11 UTC