diff --git a/fetch.bs b/fetch.bs index 434216456..af711645b 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2157,6 +2157,17 @@ Unless stated otherwise, it is false.
This flag is for exclusive use by HTML's render-blocking mechanism. [[!HTML]] +
A request has an associated boolean is HTTPS upgrade. +Unless stated otherwise, it is false. + +
This is for exclusive use by HTTPS Upgrading algorithm. + +
A request has an associated +HTTPS upgrade fallback URL, which is null or a URL. +Unless otherwise stated, it is null. + +
This is for exclusive use by HTTPS Upgrading algorithm. +
A request has an associated @@ -3265,6 +3276,106 @@ through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in +
User agents may optionally upgrade requests with URLs that are not +potentially trustworthy URLs to attempt to fetch them over +potentially trustworthy URLs. If an upgraded request fails with a network error, it is +retried over the original URL. + +
The HTTPS upgrading algorithm consists of upgrade an HTTP request and +HTTPS upgrade fallback algorithms. + +
To upgrade an HTTP request given a request request: + +
If one or more of the following conditions are met, return: +
request's destination is not "document
"
+
+
request's method is not "GET
"
+
+
request's URL's host is exempted from + upgrades in an implementation-defined way. +
If request's HTTPS upgrade fallback URL is non-null, clear + is HTTPS upgrade and HTTPS upgrade fallback URL and return. + +
This is a fallback request that shouldn't be upgraded again. + +
Otherwise, set the following fields: +
Set HTTPS upgrade fallback URL to request's + URL. + +
Set is HTTPS upgrade to true. +
To run HTTPS upgrade fallback given a request request and +response response: + +
If request's is HTTPS upgrade is not set, then return + response. + +
If response is a network error: + +
This means that the upgrade failed and initiates a fallback load. + +
Let fallbackResponse be a new response whose
+ header list is « », and its Location
header is set to
+ request's HTTPS upgrade fallback URL, and its
+ status set to 307.
+
+
Return fallbackResponse. +
Return response. + +
This means the upgrade was successful. + +
User agents can implement a fast-fallback path by canceling slow fetches on upgraded +requests, in order to quickly initiate a fallback http load. + +
a.com
serves both
+http://a.com
and https://a.com
. An eligible request to
+http://a.com
will be upgraded to https://a.com
.
+
+
a.com
serves
+http://a.com
but refuses connections on https://a.com
. An eligible
+request to http://a.com
will be upgraded to https://a.com
, but the fetch
+will fail. A fallback request will be initiated to http://a.com
.
+
+
Upgrade request to a potentially trustworthy URL, if appropriate. +
Optionally, run upgrade an HTTP request algorithm on request. + +
HTTPS upgrading only applies to requests with HTTP(S) schemes, but it's done + in main fetch instead of HTTP fetch to ensure that + upgrade a mixed content request to a potentially trustworthy URL, if appropriate + step runs next and applies to the upgraded request. +
Upgrade a mixed content request to a potentially trustworthy URL, if appropriate.
If should request be blocked due to a bad port, @@ -5157,8 +5276,6 @@ these steps:
If one of the following is true
response's type is "error
"
-
request's mode is "same-origin
" and
response's type is "cors
"
@@ -5246,6 +5363,10 @@ these steps:
CORS check, as request's client and the service worker can
have different embedder policies.
+
If request's is HTTPS upgrade is set, set response + and internalResponse to the result of running HTTPS upgrade fallback given + request and response. +
If internalResponse's status is a redirect status:
@@ -8716,7 +8837,7 @@ resource — for non-CORS requests as well as CORS
requests — and do not use `Vary
`.
-
As part of establishing a connection, the {{WebSocket}} object initiates a special kind of
fetch (using a request whose mode is
@@ -8980,6 +9101,7 @@ done only by navigations). The fetch controller is also used to
redirect mode set to "manual
".
+
Thanks to