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

@annevk 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're right. I forgot about insecure contexts. (Although I think browsers are considering not applying HSTS there.)

A problem with synthesizing a redirect that I see is that the tainted origin flag would get set, for instance. And as Mike pointed out above the same origin check wouldn't pass which means the response itself would get tainted as well. I think there's also a couple places that look at the entire request URL list at the moment, but ideally we can move all of those to use origin & tainted origin flag.

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