Re: [whatwg/fetch] Acknowledge interaction with draft-ietf-dnsop-svcb-https scheme redirect (#1325)

@mikewest commented on this pull request.



> @@ -3873,11 +3884,16 @@ steps:
    <li>Matching <var>request</var>'s <a for=request>current URL</a>'s <a for=url>host</a> per
    <a href=https://datatracker.ietf.org/doc/html/rfc6797#section-8.2>Known HSTS Host Domain Name Matching</a>
    results in either a superdomain match with an asserted <code>includeSubDomains</code> directive
-   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive).
-   [[!HSTS]]
+   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive) or

```suggestion
   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive); or
```

I think a semi-colon here would make the "or"ing a little more clear.

> @@ -3873,11 +3884,16 @@ steps:
    <li>Matching <var>request</var>'s <a for=request>current URL</a>'s <a for=url>host</a> per
    <a href=https://datatracker.ietf.org/doc/html/rfc6797#section-8.2>Known HSTS Host Domain Name Matching</a>
    results in either a superdomain match with an asserted <code>includeSubDomains</code> directive
-   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive).
-   [[!HSTS]]
+   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive) or
+   DNS resolution for the request finds a matching HTTPS RR per
+   <a href=https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-8.5>HTTP Strict Transport Security</a>.
+   [[!HSTS]][[!SVCB]]

There's a little unwinding to do here, I think, as Fetch currently doesn't resolve DNS until further down in the algorithm (part of "obtain a connection", which doesn't happen until [step 8 of "HTTP-network fetch"](https://fetch.spec.whatwg.org/#:~:text=Switch%20on%20request%E2%80%99s%20mode%3A) (which doesn't happen at all in cases where the cache/service worker handles the request)). Presumably we want to either perform that resolution earlier (presumably there's a cache of some sort we could point to), or perform this upgrade later? Perhaps splitting the HTTPS RR out into a separate implementation-defined algorithm that we could call here would be sufficient for the moment?

(Given that this is shipping today in Firefox, I think it's actually fine for us to put the call here next to HSTS for the time being to get it documented as something developers should pay attention to, but I'm not actually sure that HSTS's description here actually matches its behavior in browsers: I'd be a little surprised, for example, if the same-origin check in step 11 took HSTS into account.)

> @@ -3873,11 +3884,16 @@ steps:
    <li>Matching <var>request</var>'s <a for=request>current URL</a>'s <a for=url>host</a> per
    <a href=https://datatracker.ietf.org/doc/html/rfc6797#section-8.2>Known HSTS Host Domain Name Matching</a>
    results in either a superdomain match with an asserted <code>includeSubDomains</code> directive
-   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive).
-   [[!HSTS]]
+   or a congruent match (with or without an asserted <code>includeSubDomains</code> directive) or
+   DNS resolution for the request finds a matching HTTPS RR per
+   <a href=https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https#section-8.5>HTTP Strict Transport Security</a>.
+   [[!HSTS]][[!SVCB]]

/cc @annevk for thoughts.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1325#pullrequestreview-775974850