LGTM1. I've reviewed the Fetch PR, and while I think there's work to do to explain exactly how this work, I think we're in a good place to land initially. Thanks for putting the patch together, and good luck getting this out the door.
-mike On Fri, Oct 8, 2021 at 4:55 PM Eric Orth <erico...@chromium.org> wrote: > Update: Started a Fetch PR: https://github.com/whatwg/fetch/pull/1325 > > On Thu, Oct 7, 2021 at 3:34 AM Yoav Weiss <yoavwe...@chromium.org> wrote: > >> +1 to Mike's request. I think a Fetch PR for this seems both useful and >> not-extremely-onerous to pull together. >> >> On Thursday, September 30, 2021 at 9:20:23 PM UTC+2 Mike West wrote: >> >>> This all looks good, thanks. >>> >>> I'd like to see the Fetch PR up before we ship this. It's a little >>> surprising that neither WebKit nor Gecko wired that up, but if we have >>> three interoperable implementations, it should be quite straightforward to >>> specify. >>> >>> I also wonder a little about WPT; we should probably at least file a ` >>> type:untestable >>> <https://github.com/web-platform-tests/wpt/issues?q=is%3Aissue+is%3Aopen+label%3Atype%3Auntestable>` >>> issue to point to this as something that's not feasible to validate without >>> additional WebDriver support. >>> >>> -mike >>> >>> >>> On Thu, Sep 30, 2021 at 4:42 PM Eric Orth <erico...@chromium.org> wrote: >>> >>>> >>>> >>>> On Thu, Sep 30, 2021 at 6:53 AM Kaustubha Govind < >>>> kaustub...@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Sep 28, 2021, 2:08 PM Eric Orth <erico...@chromium.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Sep 28, 2021 at 1:13 PM Eric Orth <erico...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Sep 28, 2021 at 6:09 AM Mike West <mk...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Hey Eric! >>>>>>>> >>>>>>>> On Thu, Sep 23, 2021 at 10:36 PM Eric Orth <erico...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> erico...@chromium.org >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> >>>>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07 >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> Query DNS for HTTPS records (alongside traditional A and AAAA >>>>>>>>> queries). When a website has deployed an HTTPS DNS record and Chrome >>>>>>>>> receives it, Chrome will always connect to the website via HTTPS. >>>>>>>>> >>>>>>>>> Design doc for all Chrome DNS HTTPS plans: >>>>>>>>> https://docs.google.com/document/d/1k461sRbddjDGj7Q8f-ZKHZvmB-ENUWSdX_3Fpp2dmXQ >>>>>>>>> >>>>>>>>> This feature covers just the basic query and HTTP->HTTPS upgrade >>>>>>>>> part of those plans, and only for simpler cases that do not require >>>>>>>>> followup DNS queries by the Chrome DNS stack. >>>>>>>>> >>>>>>>>> >>>>>>>>> Blink component >>>>>>>>> >>>>>>>>> Internals>Network>DNS >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3EDNS> >>>>>>>>> >>>>>>>>> TAG review >>>>>>>>> >>>>>>>>> Not applicable. No direct changes to web platform APIs. Change is >>>>>>>>> to underlying DNS infrastructure, following an IETF spec, with only >>>>>>>>> indirect web-facing side effects. >>>>>>>>> >>>>>>>> >>>>>>>> This seems like an overly narrow take on the feature: it seems like >>>>>>>> this needs to be wired up to Fetch in order to explain how the DNS >>>>>>>> assertion turns into a decision about how to connect to sites (similar >>>>>>>> to HSTS's >>>>>>>> integration >>>>>>>> <https://fetch.spec.whatwg.org/#:~:text=Set%20request%E2%80%99s%20current%20URL%E2%80%99s%20scheme%20to%20%22https%22>), >>>>>>>> and that upgrade will have web-visible impacts. >>>>>>>> >>>>>>> >>>>>>> Seems accurate to me. All the signals and triggering happen in DNS, >>>>>>> outside web platform APIs, with no direct web-platform-API interaction, >>>>>>> e.g. a header like was done for HSTS. Then the result is a redirect, >>>>>>> which >>>>>>> yes, is web-visible, hence the "indirect web-facing side effects". >>>>>>> >>>>>>> But I think you are right that this should get at least a mention in >>>>>>> the Fetch spec, and I think the ideal situation would be a single >>>>>>> additional sentence in that point about HSTS upgrade ("[...] or a DNS >>>>>>> lookup for the request's current URL per [link to section 8.5 of SVCB >>>>>>> RFC] >>>>>>> returns an HTTPS DNS record." or something like that). Does that sound >>>>>>> reasonable to you, or do you think this will take more comprehensive >>>>>>> updates to Fetch? >>>>>>> >>>>>>> >>>>>>>> Can I assume that you'll be following the same algorithm (e.g. >>>>>>>> shifting from 80 to 443 by switching the protocol, but not altering >>>>>>>> non-standard ports)? >>>>>>>> >>>>>>> >>>>>>> Correct. Non-standard ports result in a redirect to https with the >>>>>>> same non-standard port. Also noteworthy that non-standard ports would >>>>>>> require the HTTPS DNS record to be specific to that non-standard port, >>>>>>> e.g. >>>>>>> if the request URL were "http://example.com:1234";, the redirect >>>>>>> will only happen if there is an HTTPS record for DNS queries for >>>>>>> "_1234._ >>>>>>> https.example.com", not merely at "example.com" as would be >>>>>>> sufficient if the request URL were "http://example.com[:80]";. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> Not applicable >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> Not directly part of the web API surface; only has indirect >>>>>>>>> behavior implications on the web platform in the form of the >>>>>>>>> HTTP->HTTPS >>>>>>>>> redirect triggered by DNS signals. >>>>>>>>> >>>>>>>>> HTTPS DNS records are a feature of DNS. The spec is a draft of >>>>>>>>> the IETF DNSOP working group, and while not yet a published RFC, it is >>>>>>>>> widely considered stable and ready for implementation. IANA has >>>>>>>>> designated >>>>>>>>> HTTPS as DNS resource record type 65. >>>>>>>>> >>>>>>>>> >>>>>>>>> Gecko: No signal >>>>>>>>> >>>>>>>>> WebKit: Safari has been querying HTTPS DNS records since late >>>>>>>>> 2020. Unclear if Safari has yet implemented HTTP->HTTPS redirect >>>>>>>>> behavior >>>>>>>>> of such records. >>>>>>>>> >>>>>>>> >>>>>>>> It would be helpful to ask both Gecko and WebKit developers for >>>>>>>> more clear signals as described in https://bit.ly/blink-signals. >>>>>>>> >>>>>>> >>>>>>> Okay. I'll send off those requests. >>>>>>> >>>>>> >>>>>> Update: >>>>>> Request for position sent for WebKit: >>>>>> https://lists.webkit.org/pipermail/webkit-dev/2021-September/031991.html >>>>>> >>>>>> For Gecko, I discovered an older but very relevant "worth >>>>>> prototyping" position ( >>>>>> https://mozilla.github.io/standards-positions/#dnsop-svcb-httpssvc) >>>>>> for the overall HTTPS record draft. I've updated the chromestatus entry >>>>>> with this position and added a note that Firefox engineers have since >>>>>> stayed involved in the IETF discussions. >>>>>> >>>>> >>>>> FYI, it appears that Firefox 92 performs the http->https upgrade with >>>>> HTTPS DNS records (i.e. the exact feature that this thread is discussing): >>>>> >>>>> https://www.mozilla.org/en-US/firefox/92.0/releasenotes/ >>>>> >>>> >>>> Updated the chromestatus entry. Thanks. >>>> >>>> >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> Web developers: No signals >>>>>>>>> >>>>>>>> >>>>>>>> Are there any folks lined up to use this? Presumably there are if >>>>>>>> Safari is already making these queries? >>>>>>>> >>>>>>> >>>>>>> Most of the general interest I have heard for HTTPS records is for >>>>>>> the ECH and upgrade-to-QUIC functionalities that are not part of this >>>>>>> specific planned launch. So it would be fair to say there is a lot of >>>>>>> interest from various parties for HTTPS record support in general, and >>>>>>> this >>>>>>> HTTP->HTTPS redirect functionality is a part of that standard, and it >>>>>>> is by >>>>>>> design that you cannot get those other functionalities without also >>>>>>> getting >>>>>>> the HTTP->HTTPS functionality. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> No specific DevTools support. Changes not directly part of the >>>>>>>>> web API surface. Chrome is not generally used as a development tool >>>>>>>>> for >>>>>>>>> changing DNS records besides testing/developing the indirect behavior >>>>>>>>> effects on visiting websites. >>>>>>>>> >>>>>>>> >>>>>>>> We represent HSTS to developers in devtools. Presumably we'd want >>>>>>>> to do the same for this mechanism, and signal in some way to developers >>>>>>>> _why_ a particular request was upgraded? >>>>>>>> >>>>>>> >>>>>>> I wouldn't describe it as rising to the level of "support", but >>>>>>> DNS-triggered redirect will display similarly to other artificial >>>>>>> redirect >>>>>>> responses, e.g. HSTS or extension delegates. That is that DevTools will >>>>>>> show a 307 redirect response with a "Non-Authoritative-Reason" field >>>>>>> with a >>>>>>> short string to describe the reason, e.g. "HSTS", "delegate", or for >>>>>>> DNS-triggered redirects, "DNS". I've added a note on this into the the >>>>>>> chromestatus entry. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> No >>>>>>>>> >>>>>>>>> Flag name >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> False >>>>>>>>> >>>>>>>>> Tracking bug >>>>>>>>> >>>>>>>>> https://crbug.com/1206455 >>>>>>>>> >>>>>>>>> Launch bug >>>>>>>>> >>>>>>>>> https://crbug.com/1206460 >>>>>>>>> >>>>>>>>> Estimated milestones >>>>>>>>> >>>>>>>>> Desktop 96 >>>>>>>>> >>>>>>>>> Android 96 >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://www.chromestatus.com/feature/5485544526053376 >>>>>>>>> >>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>> <https://www.chromestatus.com/>. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "net-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to net-dev+unsubscr...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcEJF4%3D7zU16oki_m0vYqfX2_%2BXgH2Fxf51RnMv9ipx63w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "net-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to net-dev+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcH4nkQuyH4TxsMoHOXRqLSOLrxNkQv0WYTt2d7LC98VgA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "net-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to net-dev+unsubscr...@chromium.org. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcFFMkuhWjP-cMg%2BAH_Sr_DdHESEowQgDkh_tnF7Fy1t8A%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAMOjQcFFMkuhWjP-cMg%2BAH_Sr_DdHESEowQgDkh_tnF7Fy1t8A%40mail.gmail.com?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 on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMOjQcHTz_PWTUQG_7LyQORzB9s4x5AVMp9QGRTLSQADe%2B1kqA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMOjQcHTz_PWTUQG_7LyQORzB9s4x5AVMp9QGRTLSQADe%2B1kqA%40mail.gmail.com?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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DfqDL-QEYEYEU%2B3yxC7oCYqGNU08cfknLSaLK74kDv7vg%40mail.gmail.com.
