LGTM3 with the same conditional. Thanks! On Thu, Oct 14, 2021 at 12:06 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d43a48a1-16fc-4d57-bbe9-8c054f27e851n%40chromium.org?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/CAOMQ%2Bw9xPJvvy4yWEeY3jzX0Lm6Pvdu1zWOe5YKP8q1MTKV5og%40mail.gmail.com.
