Specify value of Origin header (CORS) after a scheme upgrade

[Rob--W]

UIR (and HSTS) are commonly implemented as an internal redirect from http to https (at least in Firefox and Chrome, AFAIK). This has implications for CORS, and the last thread I found on this was unresolved (https://github.com/whatwg/fetch/issues/324).

A central concept in CORS is "Origin", visible as a request header, defined at https://fetch.spec.whatwg.org/#serializing-a-request-origin as:

Serializing a request origin, given a request request, is to run these steps:

1. If request has a redirect-tainted origin, then return "null".
2. Return request’s origin, serialized.

The request is considered to have a "redirect-tainted origin" when any of the origins in the redirect chain are same-origin.

When UIR is implemented as a redirect, a cross-origin fetch to http://example.com is immediately followed by a (cross-origin) redirect to https://example.com. According to the above spec, the origin would therefore be null. An argument can however be made for not tainting the Origin when a request is upgraded through UIR/HSTS.

Test case: https://jsfiddle.net/0kq28zgj/1/

In practice, current versions of Chrome (107) and Safari (15.6) send the original Origin. Firefox (108) currently sends Origin: null, but internally uses the original Origin (and breaks CORS when the server mirrors Origin in Access-Control-Allow-Origin). I believe that this is a bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1800990), so once fixed, it looks like all major browsers will treat UIR/HSTS/extension-initiated scheme upgrades as a non-tainting redirect.

Should we codify this behavior in the UIR spec and/or the fetch spec?

[annevk]

It should be part of Fetch if it isn't already.

[Rob--W]

I have moved this ticket to https://github.com/whatwg/fetch/issues/1551