From 53fb61ac77e7dfe6f300c9357edbc1e76edb3ec5 Mon Sep 17 00:00:00 2001 From: Carlos IL Date: Tue, 21 Mar 2023 20:23:25 +0000 Subject: [PATCH 1/4] Add HTTPS Upgrading HTTPS Upgrading automatically and optimistically upgrades all HTTP navigations to HTTPS, with a fallback to HTTP. If an upgraded navigation fails, the user agent will fallback to the original HTTP navigation. Tests: web-platform-tests/wpt/tree/HEAD/https-upgrades --- fetch.bs | 139 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 137 insertions(+), 2 deletions(-) diff --git a/fetch.bs b/fetch.bs index 58579420d..481b7fa08 100644 --- a/fetch.bs +++ b/fetch.bs @@ -2162,6 +2162,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. + +

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. +

A request has an associated @@ -3270,6 +3281,120 @@ through TLS using ALPN. The protocol cannot be spoofed through HTTP requests in +

HTTPS upgrading

+ +

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. + + +

HTTPS upgrade algorithm

+ +
+

To upgrade an HTTP request given a request request: + +

    +
  1. +

    If one or more of the following conditions are met, return: +

    +
    2. + +
  2. +

    If request's HTTPS upgrade fallback URL is non-null, set + is HTTPS upgrade to false and HTTPS upgrade fallback URL to + null and return. + +

    This is a fallback request that cannot be upgraded again. + +

  3. +

    Otherwise: +

    +
    4. +
+
+ + +

Fallback algorithm

+ +
+

To run HTTPS upgrade fallback given a request request and +response response: + +

    +

  1. If request's is HTTPS upgrade is false, then return + response. + +

  2. +

    If response is a network error: + +

    This means that the upgrade failed and initiates a fallback load. + +

      +

    1. Let serializedFallbackUrl be the request's + HTTPS upgrade fallback URL, serialized and + isomorphic encoded. + +

    2. Let fallbackResponse be a new response whose + header list is « + (`Location`, serializedFallbackUrl) » and + status is 307. + +

    3. Return fallbackResponse. +

    + +
  3. +

    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 fetch. +

+ + +

Examples

+ +

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. + +

site.test serves +http://site.test but refuses connections on https://site.test. Upon +first request and fallback to http://site.test, the user agent stores the hostname +in an allowlist with an expiration time of 7 days. In a future request, if site.test +is still in this allowlist, the user agent will not upgrade http://site.test to +https://site.test. The user agent will also set the new expiration time of the +allowlist entry for site.test to 7 days from now. + +

HTTP extensions

@@ -4457,6 +4582,14 @@ steps:

  • 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, @@ -6001,7 +6134,8 @@ optional boolean forceNewConnection (default false), run these steps: canceled:

      -

    1. If connection is failure, then return a network error. +

    2. If connection is failure, then return the result of running + HTTPS upgrade fallback given request and network error.

    3. Set timingInfo's final connection timing info to the result of calling clamp and coarsen connection timing info with @@ -8727,7 +8861,7 @@ resource — for non-CORS requests as well as CORS requests — and do not use `Vary`. -

      WebSockets

      +

      WebSockets

      As part of establishing a connection, the {{WebSocket}} object initiates a special kind of fetch (using a request whose mode is @@ -8991,6 +9125,7 @@ done only by navigations). The fetch controller is also used to redirect mode set to "manual". +

      Acknowledgments

      Thanks to From 7a6ce0db36b54b3911e38904be9318c57a3c7aa0 Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Tue, 28 Nov 2023 17:55:08 +0100 Subject: [PATCH 2/4] nits --- fetch.bs | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/fetch.bs b/fetch.bs index 481b7fa08..3f43ace47 100644 --- a/fetch.bs +++ b/fetch.bs @@ -3299,22 +3299,25 @@ retried over the original URL.

      1. -

        If one or more of the following conditions are met, return: +

        If any of the following are true: +

        + +

        then return.

      2. -

        If request's HTTPS upgrade fallback URL is non-null, set +

        If request's HTTPS upgrade fallback URL is non-null, then set is HTTPS upgrade to false and HTTPS upgrade fallback URL to null and return. @@ -3322,7 +3325,8 @@ retried over the original URL.

      3. Otherwise: -

        +
    @@ -3352,13 +3356,13 @@ retried over the original URL.

    This means that the upgrade failed and initiates a fallback load.

      -

    1. Let serializedFallbackUrl be the request's +

    2. Let serializedFallbackURL be the request's HTTPS upgrade fallback URL, serialized and isomorphic encoded.

    3. Let fallbackResponse be a new response whose header list is « - (`Location`, serializedFallbackUrl) » and + (`Location`, serializedFallbackURL) » and status is 307.

    4. Return fallbackResponse. @@ -6135,7 +6139,7 @@ optional boolean forceNewConnection (default false), run these steps:

      1. If connection is failure, then return the result of running - HTTPS upgrade fallback given request and network error. + HTTPS upgrade fallback given request and a network error.

      2. Set timingInfo's final connection timing info to the result of calling clamp and coarsen connection timing info with From 60a6b1ace333ca7801b88f6da048f7c8bbe1fe4e Mon Sep 17 00:00:00 2001 From: Mustafa Acer Date: Thu, 14 Dec 2023 10:30:43 -0800 Subject: [PATCH 3/4] Remove the note for the upgrade step --- fetch.bs | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/fetch.bs b/fetch.bs index 3f43ace47..ce176a257 100644 --- a/fetch.bs +++ b/fetch.bs @@ -4586,13 +4586,7 @@ steps:

      3. Upgrade request to a potentially trustworthy URL, if appropriate. -

      4. -

        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. +

      5. Optionally, run upgrade an HTTP request algorithm on request.

      6. Upgrade a mixed content request to a potentially trustworthy URL, if appropriate. From 377824d920aa9c96cc8b068cb246e6e6a1466922 Mon Sep 17 00:00:00 2001 From: Mustafa Emre Acer Date: Thu, 21 Nov 2024 11:30:14 -0800 Subject: [PATCH 4/4] Add custom port and redirect examples, move the upgrade step --- fetch.bs | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/fetch.bs b/fetch.bs index ce176a257..f4b4996e2 100644 --- a/fetch.bs +++ b/fetch.bs @@ -3307,7 +3307,10 @@ retried over the original URL.

      7. request's method is not "GET";

      8. request's URL's scheme is not - "http"; or + "http"; + +

      9. request's URL's port is not the default + port; or

      10. request's URL's origin is exempted from upgrades in an implementation-defined way, @@ -3390,13 +3393,25 @@ requests, in order to quickly initiate a fallback HTTP fetch. 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. -

        site.test serves -http://site.test but refuses connections on https://site.test. Upon -first request and fallback to http://site.test, the user agent stores the hostname -in an allowlist with an expiration time of 7 days. In a future request, if site.test -is still in this allowlist, the user agent will not upgrade http://site.test to -https://site.test. The user agent will also set the new expiration time of the -allowlist entry for site.test to 7 days from now. +

        a.com serves +http://a.com but refuses connections on https://a.com. Upon +first request and fallback to http://a.com, the user agent stores the hostname +in an allowlist with an expiration time of 7 days. In a future request, if a.com +is still in this allowlist, the user agent will not upgrade http://a.com to +https://a.com. The user agent will also set the new expiration time of the +allowlist entry for a.com to 7 days from now. + +

        a.com serves +http://a.com:8080. When a site is served from a non-default HTTP port, it's unlikely +that the corresponding HTTPS URL is served from the default port either. Therefore, the user agent +doesn't upgrade requests to http://a.com:8080. + +

        a.com serves +http://a.com and https://a.com. The latter redirects to the former. +An eligible request to http://a.com will be upgraded to +https://a.com and will be redirected back to http://a.com. +The user agent will detect this as a redirect loop, treat it as a failed upgrade and initiate a +fallback navigation to http://a.com. @@ -4586,8 +4601,6 @@ steps:

      11. Upgrade request to a potentially trustworthy URL, if appropriate. -

      12. Optionally, run upgrade an HTTP request algorithm on request. -

      13. Upgrade a mixed content request to a potentially trustworthy URL, if appropriate.

      14. If should request be blocked due to a bad port, @@ -4635,6 +4648,8 @@ steps: in the fetch algorithm and potentially unwind logic on discovering the need to change request's current URL's scheme. +

      15. Optionally, run upgrade an HTTP request algorithm on request. +

      16. If recursive is false, then run the remaining steps in parallel.