I think this would be in Step 10 of Main Fetch (Step 5 is for Upgrade-Insecure-Requests): > > Set request’s current URL > <https://fetch.spec.whatwg.org/#concept-request-current-url>’s scheme > <https://url.spec.whatwg.org/#concept-url-scheme> to "https" if all of > the following conditions are true: > > - request’s current URL > <https://fetch.spec.whatwg.org/#concept-request-current-url>’s scheme > <https://url.spec.whatwg.org/#concept-url-scheme> is "http" > - request’s current URL > <https://fetch.spec.whatwg.org/#concept-request-current-url>’s host > <https://url.spec.whatwg.org/#concept-url-host> is a domain > <https://url.spec.whatwg.org/#concept-domain> > - Matching request’s current URL > <https://fetch.spec.whatwg.org/#concept-request-current-url>’s host > <https://url.spec.whatwg.org/#concept-url-host> per Known HSTS Host > Domain Name Matching > <https://www.rfc-editor.org/rfc/rfc6797.html#section-8.2> results in > either a superdomain match with an asserted includeSubDomains directive > or a congruent match (with or without an asserted includeSubDomains > directive) [HSTS] <https://fetch.spec.whatwg.org/#biblio-hsts>; or > DNS resolution for the request finds a matching HTTPS RR per section > 9.5 > > <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-9.5> > of [SVCB] <https://fetch.spec.whatwg.org/#biblio-svcb>. [HSTS] > <https://fetch.spec.whatwg.org/#biblio-hsts> [SVCB] > <https://fetch.spec.whatwg.org/#biblio-svcb> > > So maybe just add a fourth condition "request's current URL's host is not localhost"?
On Thu, Oct 24, 2024 at 8:42 AM Eric Lawrence <bay...@gmail.com> wrote: > > probably makes sense to start by suggesting a change to > https://fetch.spec.whatwg.org/#concept-main-fetch, > > but the editors there might ask you to write an update to the RFC. > > I don't think I understand what change to Fetch would be proposed. The > section you flagged has two relevant clauses related to HTTPS upgrades: > > 5. Upgrade request to a potentially trustworthy URL, if appropriate. > 6. Upgrade a mixed content request to a potentially trustworthy URL, if > appropriate. > > Notably, [*.]localhost is already a potentially trustworthy URL: > https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy, > clause #5. > > ...which implies to me that the behavior I propose is already what Fetch > asks for. > On Wednesday, October 23, 2024 at 7:12:28 PM UTC-5 Jeffrey Yasskin wrote: > >> Can you propose a matching change to the relevant standard? It probably >> makes sense to start by suggesting a change to >> https://fetch.spec.whatwg.org/#concept-main-fetch, but the editors there >> might ask you to write an update to the RFC. We can figure out the cheapest >> way to get that done if they do ask. There's no need to block shipping this >> on getting the updates finished, but the launch process >> <https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship:~:text=propose%20that%20the%20feature%20migrate%20to%20a%20working%20group> >> does >> say to propose it first. >> >> Jeffrey >> >> On Wed, Oct 23, 2024 at 2:28 PM 'Eric Lawrence' via blink-dev < >> blin...@chromium.org> wrote: >> >>> *Following up on an earlier thread >>> here: https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0 >>> <https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0>* >>> >>> Contact emails: eri...@microsoft.com >>> >>> Explainer: None >>> >>> Specification: HSTS specification is at >>> https://datatracker.ietf.org/doc/html/rfc6797; this feature proposes an >>> improvement. >>> >>> Summary >>> >>> Strict-Transport-Security response headers can cause problems for >>> localhost web servers because STS applies host-wide, across all ports. This >>> causes compatibility problems for web developers testing locally as well as >>> end-users who use software packages that commonly spin up localhost >>> webservers for ephemeral reasons (e.g. communication of an auth token from >>> a web login to a local software package). If one local listener sets >>> Strict-Transport-Security on a localhost response, it will be applied to >>> all subsequent localhost requests regardless of port. We resolve this >>> problem by ignoring Strict-Transport-Security headers on responses from >>> localhost URLs. >>> >>> Blink component: Internals>Network>DomainSecurityPolicy >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EDomainSecurityPolicy> >>> >>> TAG review: None >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> The expectation is that this will improve compatibility with services >>> that run on localhost by avoiding unexpected interactions across unrelated >>> packages. >>> >>> *Gecko*: Shipped/Shipping >>> >>> *WebKit*: No signal >>> >>> *Web developers*: Positive ( >>> https://issues.chromium.org/issues?q=HSTS%20localhost) Web Developers >>> who test their sites locally commonly report problems with >>> Strict-Transport-Security headers applying unexpectedly across unrelated >>> localhost services under tests. >>> >>> *Other signals*: >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> None >>> >>> >>> Debuggability >>> >>> HSTS upgrades show in the F12 Network pane as "307 Internal Redirect." >>> In the absence of such an upgrade, the 307 is not shown. >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? Yes. >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? No, HSTS is not tested by Web Platform tests. The change is tested by >>> Chrome unit and browser tests. >>> >>> Flag name on chrome://flags: None >>> >>> Finch feature name: None >>> >>> Non-finch justification: None >>> >>> Requires code in //chrome? All of the functional changes are in /net/ >>> but tests under /chrome/ require updates to use non 'localhost' test >>> endpoints. >>> >>> Tracking bug https://issues.chromium.org/issues/41251622; CL: >>> https://chromium-review.googlesource.com/c/chromium/src/+/5923046 >>> <https://chromium-review.googlesource.com/c/chromium/src/+/5923046> >>> >>> Estimated milestones >>> Shipping on desktop >>> 132 >>> Shipping on Android >>> 132 >>> >>> Anticipated spec changes >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> None >>> >>> Link to entry on the Chrome Platform Status: >>> https://chromestatus.com/feature/5134293196865536?gate=5113092281991168 >>> >>> Links to previous Intent discussions: >>> https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/gGHOmFGEzQ0 >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+...@chromium.org. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d6c447c-32ba-46af-b04e-828e69b38322n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8d6c447c-32ba-46af-b04e-828e69b38322n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b81818f0-73ef-4703-af4c-8f8fcefd93d2n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b81818f0-73ef-4703-af4c-8f8fcefd93d2n%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALMy46RyuanWjP4eb5NOW4DWS%2Bb7hT-bV%3DSgxo4g57iHzLRk5g%40mail.gmail.com.
