Okay, I've proposed a tweak. https://github.com/whatwg/fetch/pull/1781
On Thursday, October 24, 2024 at 1:13:18 PM UTC-5 Jeffrey Yasskin wrote: > Yes, exactly. > > On Thu, Oct 24, 2024 at 8:46 AM Chris Thompson <cth...@chromium.org> > wrote: > >> 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+...@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/7c28576e-bee4-430e-8a8d-40c9f23fd6c8n%40chromium.org.
