LGTM2 conditional on landing the PR On Monday, October 11, 2021 at 8:47:09 PM UTC+2 Mike West wrote:
> 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/d43a48a1-16fc-4d57-bbe9-8c054f27e851n%40chromium.org.
