Redirects to HTTP: If a navigation would result in a redirect to HTTP, that redirection should also get upgraded to HTTPS. This applies both to navigations that are initially to HTTP URLs which get upgraded to HTTPS (and then redirected to an HTTP URL) and to navigations that are initially to HTTPS URLs that are redirected to HTTP. If these upgrades result in a redirect loop (for example, https://http.badssl.com/ redirects to http://http.badssl.com/, which would be upgraded to https://http.badssl.com/, and so on), this should be considered a failed upgrade.
@annevk suggested that this should be covered by the 20 redirect limit and asked for a separate issue here.
An example for which we have an issue is a page which redirects after a timeout. (www.bom.gov.au) gets upgraded and then redirects to (http://www.bom.gov.au/akamai/https-redirect.html) which redirects using window.location.replace after 10 seconds. In this case relying on the 20 redirects limit would take over 3 minutes.
What is the issue with the Fetch Standard?
This came up in the context of HTTPS upgrades. It was discussed in the initial explainer here: https://github.com/dadrian/https-upgrade/blob/main/explainer.md#proposed-behavior-change
@annevk suggested that this should be covered by the 20 redirect limit and asked for a separate issue here.
An example for which we have an issue is a page which redirects after a timeout. (www.bom.gov.au) gets upgraded and then redirects to (http://www.bom.gov.au/akamai/https-redirect.html) which redirects using window.location.replace after 10 seconds. In this case relying on the 20 redirects limit would take over 3 minutes.
The spec does state that requests can be exempt in an "implementation defined way". Chrome seems to have explicit loop detection: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/chrome/browser/ssl/https_upgrades_interceptor.cc#519
Of course, the example above also uses a JS based redirect so it may be impossible to define a satisfying solution here.