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]]

You are absolutely right that this is simplifying things quite a bit, and there's quite a bit of room for different user agents to implement DNS and HTTPS scheme upgrades differently while achieving the same overall effects important to the Fetch spec.  (For the record, Chrome's implementation waits until the normal point of host resolution in the connection logic.  If that logic finds an HTTPS record for an "http://"-scheme request, it returns an error that unwinds quite a bit of the fetch attempt before getting treated as a redirect to the "https://" URL.)

That said, I think the important goal for this PR is just to get some language and notes in acknowledging that this upgrade is something going on, not to fully spec it out and figure out a canonical way to implement the behavior.  As you note, get it "documented as something developers should pay attention to".  It seems apparent that different user agents are fine with starting to implement this behavior just from the IETF specs, and there doesn't seem to be any big interoperability concern between the different implementations.  I think it would be a dangerous road to start trying to over specify when and how the browser interacts with DNS.

How about I add an extra sentence to the note (that currently talks about how getting HTTPS from DNS is implementation-defined): "As DNS operations are not traditionally performed until attempting to <a>obtain a connection</a>, user agents might need to perform DNS operations earlier, consult local DNS caches, or wait until later in the fetch process and potentially unwind logic on discovery the need to change <var>request</var>'s <a for=request>current URL</a>'s <a for=url>scheme</a>."?

-- 
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#discussion_r726495476