Status of h3 alpn to avoid alt-svc

[Hayden Livingston]

Hello,

I'm from the embedded developer community and we're very happy to know
that there is this proposal that allows a client (like Chrome) to
query DNS and do an HTTP/3 request without requiring alt-svc header
upgrade from http/1.1

Is there any way to track this work when it will arrive in a build of Chrome.

We're building out our 2024 product roadmap and one of the engineering
debt problem we want to solve is removal of TCP/IP stack for our
product, because we only support Chrome as a client to communicate
with our product.

Any pointers to a bug or task will help!

[Hayden Livingston]

I found the design doc by horo@

https://docs.google.com/document/d/1tHs83mfEApJ8ZQzW9E2CqkiztF4zN-ezyoVYROkCdKQ/edit#

But I don't know which version of Chrome enables this by default. We
want to know when it will be available in a public downloadable
version of chrome without feature/experiment flags to be set.

[Tsuyoshi Horo]

Hi. Thank you for reaching out to me.

This is the status page: https://chromestatus.com/feature/5154357283651584

This feature is not enabled by default yet. We are still experimenting with this feature. And no launch date has been determined.

You can enable this feature by setting chrome://flags/#use-dns-https-svcb-alpn.

And also if you are developing a Chromium based browser, you can enable features::kUseDnsHttpsSvcbAlpn.

 

[Hayden Livingston]

Thank you Tsuyoshi. But will you not ship it? This is EXTREMELY
important for our product. We don't ship Chromium, but we require
Chrome as the only supported browser, but our users are not technical,
they cannot set flags.

Without this, we will need to ship TCP/IP stack in our device which is
a major burden. Please see this is a feature of this work you are
doing, enabling the IOT embedded industry to not have TCP/IP stack.

[David Benjamin]

We experiment with features while they're in development. It is certainly a useful mechanism and hopefully we will indeed fully launch it later, but we're still working on it. It's also quite early days for the HTTPS record itself, and we're still working through fetching it reliably / in all cases. Alas, I don't think you can rely on HTTPS-RR + HTTP/3 to be the only way to connect to a service right now. On top of that, some networks don't tolerate QUIC, we at least used to run holdback experiments (though I'm not sure what the status of those are), etc.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMxMwyJ8Kt%3Dh3LnK7gtxQcit1khnxLPAzHP6a-7AF%3D9VrVWKmw%40mail.gmail.com.

[Hayden Livingston]

Any new developments on this front? Is it now enabled by default in some version of Chrome?

David, for our use case this is 100% viable. We are a very large router manufacturer and we need to host a Linux system just to be able to use TCP/IP so that our users can use Chrome to manage the system. If Chrome makes this setting default, we will be able to eliminate TCP/IP and Linux kernel and instead have a simple program that will be the DNS server + QUIC server so during initial router setup they can manage us and we will free up attack surface area and system resources.

Please tell us when this will become a default setting in Chrome.

[Debin Zhang]

Is there an update to this feature? I tested it on the latest Chrome browser, and it doesn't seem to work.

Thanks

Debin