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

@ericorth 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
+   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]]

And finally coming back to this after a lot of completely unrelated delays on my time.  Sorry, all, for leaving this hanging so long.

I added the extra bit of text I proposed long ago to further acknowledge that the DNS queries may not occur until connection time and to acknowledge that there's a lot of wishy-washing "implementation-defined" going on here.

Is this looking like an overall reasonable PR to people, or is there a strong desire for HTTPS RRs to be more completely specified within Fetch? I personally don't think there's much value in specifying it more completely, and I don't see how it could be done without either way over-specifying it or significantly reworking huge portions of Fetch way beyond what I feel I am personally comfortable or capable of writing up myself.

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

Message ID: <whatwg/fetch/pull/1325/review/887627878@github.com>