Intent to Ship: HTTP->HTTPS redirect for HTTPS DNS records

907 views
Skip to first unread message

Eric Orth

unread,
Sep 23, 2021, 4:36:32 PM9/23/21
to blink-dev, net-dev

Contact emails

eric...@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


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.


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.


Web developers: No signals



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.



Is this feature fully tested by web-platform-tests?

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.


Mike West

unread,
Sep 28, 2021, 6:09:35 AM9/28/21
to Eric Orth, blink-dev, net-dev
Hey Eric!

On Thu, Sep 23, 2021 at 10:36 PM Eric Orth <eric...@chromium.org> wrote:

Contact emails

eric...@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


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), and that upgrade will have web-visible impacts. 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)?

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

Web developers: No signals


Are there any folks lined up to use this? Presumably there are if Safari is already making these queries?
 

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?
 


Is this feature fully tested by web-platform-tests?

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.


--
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+u...@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.

Eric Orth

unread,
Sep 28, 2021, 1:13:31 PM9/28/21
to Mike West, blink-dev, net-dev
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 <eric...@chromium.org> wrote:

Contact emails

eric...@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


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), 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.
 

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.

Eric Orth

unread,
Sep 28, 2021, 2:08:42 PM9/28/21
to Mike West, blink-dev, net-dev
Update:

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.

Mike West

unread,
Sep 28, 2021, 3:32:03 PM9/28/21
to Eric Orth, blink-dev, net-dev
On Tue, Sep 28, 2021 at 7:13 PM Eric Orth <eric...@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 <eric...@chromium.org> wrote:

Contact emails

eric...@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


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), 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".

I won't quibble here, since we agree we need to modify Fetch to support the feature. :)

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?

I think we can probably best tackle this in a PR against the Fetch spec. Adding something along these lines is likely correct, but I'm not sure what the spec's editors want to do with DNS generally ("resolve a domain" is somewhat sparse, for instance) so there might be some wordsmithing to work through.

There's also some mild disagreement about whether or not this should be treated as a redirect (https://github.com/whatwg/fetch/issues/324) that this might resurface given the disagreement in modeling between the ID and Fetch. I don't think we'd need to block this on that though.

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.

Great!
 
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]".

I didn't get that from the algorithm in https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-8.5 at all. I see it now in the example at https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-10.3.1, but it's not clear to me where that mapping is defined. https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-2.3 maybe? But I don't see how that's wired up to the algorithm you pointed to. I'm probably missing something. :)

 

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.

Thank you!
 

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.

Got it, thanks. Are there any tools developers could use to check the HTTPS records they're publishing?

Kaustubha Govind

unread,
Sep 30, 2021, 6:53:56 AM9/30/21
to Eric Orth, Mike West, blink-dev, net-dev
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/


Eric Orth

unread,
Sep 30, 2021, 10:42:47 AM9/30/21
to Kaustubha Govind, Mike West, blink-dev, net-dev
Updated the chromestatus entry.  Thanks.

Mike West

unread,
Sep 30, 2021, 3:20:18 PM9/30/21
to Eric Orth, Kaustubha Govind, blink-dev, net-dev
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` issue to point to this as something that's not feasible to validate without additional WebDriver support.

-mike


Yoav Weiss

unread,
Oct 7, 2021, 3:34:06 AM10/7/21
to blink-dev, Mike West, Kaustubha Govind, blink-dev, net-dev, Eric Orth
+1 to Mike's request. I think a Fetch PR for this seems both useful and not-extremely-onerous to pull together.

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Eric Orth

unread,
Oct 8, 2021, 10:56:00 AM10/8/21
to Yoav Weiss, blink-dev, Mike West, Kaustubha Govind, net-dev
Update: Started a Fetch PR: https://github.com/whatwg/fetch/pull/1325

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

--
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+u...@chromium.org.

--
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+u...@chromium.org.

Mike West

unread,
Oct 11, 2021, 2:47:04 PM10/11/21
to Eric Orth, Yoav Weiss, blink-dev, Kaustubha Govind, net-dev
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


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+...@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.

Yoav Weiss

unread,
Oct 14, 2021, 3:06:05 PM10/14/21
to blink-dev, Mike West, Yoav Weiss, blink-dev, Kaustubha Govind, net-dev, Eric Orth
LGTM2 conditional on landing the PR

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Chris Harrelson

unread,
Oct 14, 2021, 3:06:44 PM10/14/21
to Yoav Weiss, blink-dev, Mike West, Kaustubha Govind, net-dev, Eric Orth
LGTM3 with the same conditional. Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

--
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+u...@chromium.org.

--
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+u...@chromium.org.

--
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+...@chromium.org.

--
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+...@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.

Ralf Weber

unread,
Oct 15, 2021, 1:52:58 PM10/15/21
to Eric Orth, blink-dev, net-dev
Moin!

On 23 Sep 2021, at 22:36, Eric Orth wrote:
> Estimated milestones
>
> Desktop 96
>
> Android 96
>
> Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5485544526053376

Sorry to maybe ask obvious questions, but I am new to this group and
just been tracking it for this specific feature.

Now if I read the above correct the current Chrome Dev channel build (
for me 96.0.4664.9 on Intel MacOS) should have this feature, however I
don’t see HTTPS (DNS Type 65) queries send even if I set a DoH
resolver. Am I missing something or is this not yet implemented?

TIA and so long
-Ralf
—--
Ralf Weber

Eric Orth

unread,
Oct 15, 2021, 2:51:36 PM10/15/21
to Ralf Weber, blink-dev, net-dev
The feature is implemented as of 96.0.4645.0, but whether or not it runs is controlled by experiment flags.  We currently have those flags enabled for 50% of Canary/Dev users to allow comparison against a disabled control.  Sounds like you might be in the "control" 50%.

To force the experiment:
chrome.exe --enable-features="UseDnsHttpsSvcb<DnsHttpsSvcbSchemeUpgrade.ForcedOn_UseDnsHttpsSvcb:UseDnsHttpsSvcbEnableInsecure/true/UseDnsHttpsSvcbHttpUpgrade/true/UseDnsHttpsSvcbExtraTimeAbsolute/500ms/UseDnsHttpsSvcbExtraTimePercent/50"

That should hopefully give the same behavior as what we are currently using in the "enabled" 50%.  Note that forcing this is definitely not "supported", and we might be tweaking the experiment parameters to no longer match this specific invocation.  So overall, I would only recommend using this to experiment with it.

Ralf Weber

unread,
Oct 19, 2021, 4:18:59 AM10/19/21
to Eric Orth, blink-dev, net-dev
Moin!

On 15 Oct 2021, at 20:51, Eric Orth wrote:

> The feature is implemented as of 96.0.4645.0, but whether or not it runs is
> controlled by experiment flags. We currently have those flags enabled for
> 50% of Canary/Dev users to allow comparison against a disabled control.
> Sounds like you might be in the "control" 50%.
>
> To force the experiment:
> chrome.exe
> --enable-features="UseDnsHttpsSvcb<DnsHttpsSvcbSchemeUpgrade.ForcedOn_UseDnsHttpsSvcb:UseDnsHttpsSvcbEnableInsecure/true/UseDnsHttpsSvcbHttpUpgrade/true/UseDnsHttpsSvcbExtraTimeAbsolute/500ms/UseDnsHttpsSvcbExtraTimePercent/50"
Thanks a lot that did work and I got a better understanding of the traffic now. Will the experiment also be done in beta and stable? The actual question is when and at what rate will operators of DNS resolvers see traffic increases because of this?

Eric Orth

unread,
Oct 19, 2021, 11:23:08 AM10/19/21
to Ralf Weber, blink-dev, net-dev
Yes.  Chrome 96 should start going to Beta this week, and we will most likely be turning the experiment up to 50% on Beta sometime next week.  And sometime after Chrome 96 hits Stable (late November), we will begin a careful and gradual rollout of the feature, but the details and timeline there are very much still TBD.

Ralf Weber

unread,
Oct 19, 2021, 1:09:39 PM10/19/21
to Eric Orth, blink-dev, net-dev
Moin!

On 19 Oct 2021, at 17:22, Eric Orth wrote:

> Yes. Chrome 96 should start going to Beta this week, and we will most
> likely be turning the experiment up to 50% on Beta sometime next week. And
> sometime after Chrome 96 hits Stable (late November), we will begin a
> careful and gradual rollout of the feature, but the details and timeline
> there are very much still TBD.
Thanks a lot for the quick reply. I will continue to watch traffic. I assume
that the details will be announced here so I continue to watch this space.

So long
-Ralf
—--
Ralf Weber

Eric Orth

unread,
Oct 28, 2021, 4:47:23 PM10/28/21
to Ralf Weber, blink-dev, net-dev
We just started rolling the behavior to 50% on Chrome Beta.

Eric Orth

unread,
Apr 19, 2022, 11:10:04 AM4/19/22
to blink-dev, net-dev
Long-overdue update:
After discovering a blocking bug that would have prevented the upgrade from working successfully in many cases as well as the Fetch PR mentioned above taking much longer than expected, we are now looking ready for this launch again, now targeting Chrome 102.  The behavior has been rolled back to 50% on Chrome Dev/Canary and 0% on Beta, in anticipation of rolling to 50% Beta when Chrome 102 is widely available there in the next week or two.

Anon ymous

unread,
Aug 3, 2022, 4:02:27 PM8/3/22
to blink-dev, Eric Orth, net-dev
whats the status of this now? how can I use it?

Eric Orth

unread,
Aug 4, 2022, 3:13:03 PM8/4/22
to Anon ymous, blink-dev, net-dev
Current status: We are partway through a gradual rollout of the feature, to be complete in approximately one month.  So Chrome will currently request HTTPS records and perform scheme upgrades accordingly for some but not all users.

eoBryan

unread,
Aug 4, 2022, 9:47:55 PM8/4/22
to blink-dev, Eric Orth, blink-dev, net-dev, Anon ymous
mo,
Reply all
Reply to author
Forward
0 new messages