net/http: support HTTP/3

[johanbrandhorst]

I searched for an issue to track progress of implementing HTTP/3 in the standard library but couldn't find one, so I'm opening this new issue to track this (presumably inevitable) effort.

HTTP/3 is still an IETF draft, so there's not too much point starting work on this yet. The relevant spec is (currently) available here: https://quicwg.org/base-drafts/draft-ietf-quic-http.html.

Some questions we may want to answer before any work starts:

1. Should work on this start in one of the x repos, like HTTP/2 did?
2. What if any existing libraries can be used as a base for the new HTTP/3 work?

Of note is an existing attempt at implementing QUIC and HTTP/3 in pure go: https://github.com/lucas-clemente/quic-go.

[dsymonds]

Cloudflare now supports HTTP/3, and Chrome and Firefox will shortly start supporting it: https://blog.cloudflare.com/http3-the-past-present-and-future/

[rajveermalviya]

Not to say we're in a race, but node has started implementing quic protocol in a draft PR.

Reference

Now, some bad opinions (if the go team is accepting them):

• net package - dedicated raw quic protocol API, just as tcp/udp?
• net/http package - http/3 server to be enabled explicitly from an environment variable but http/2 & lower supported implicitly using port reuse between udp (quic;http3) & tcp (http2/http1.1) sockets?

[trivikr]

but node has started implementing quic protocol in a draft PR.

Correction: The Node.js QUIC implementation began back in Q1 2019, the draft PR is the result of all that work nodejs/node#23064

[vyrwu]

Is there any progress on this? There are some existing open-source libs like quic-go that can be used for experimenting with quic, but it would be really neat to have something experimental from the std go lib.

[hekmon]

🚀
https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

[hherman1]

Has there been any word from leadership on whether or not this will be supported?

[ianlancetaylor]

I'm not sure which leadership you are asking about.

I think it's clear that Go must support HTTP/3. This issue is a good place to record the work that needs to be done. But it is one thing to say "we must do this" and it is a very different thing to say "this is how it will be done."

[hherman1]

Sorry I’m not sure how that came off, I was just wondering if there was any official word on if this will be supported. Couldn’t find any on the issue tracker. Thanks for the quick answer though!

[sylr]

It seems to me that it is still a long way from now to we must do this.

I might have missed it but so far I did not see any interest shown in this subject from any of the net & net/http usual committers. Also a research about HTTP/3 or QUIC in golang-dev does not seem to yield any significant results.

It would be nice to see a discussion started amongst people actually capable of bringing it into the standard library.

[makeworld-the-better-one]

Golang might be behind the times for this feature.

It's worth noting that HTTP/3 is not finalized by the IETF at this point. It is not enabled by default in Firefox and has experimental support. Google likes to push this protocol forward a lot and is using it already in Chrome, but it is still experimental and not finalized. I understand the Go team hesitating to start supporting a protocol that isn't even complete yet.

[mholt]

Hmm, well, Go's standard library has never been one to quickly adopt new technologies -- not without a lot of scrutiny. HTTP/2 might possibly be the exception, but even it was not vendored in from an external package until well after the spec was standardized. HTTP/3 isn't finished being standardized yet.

HTTP/3 is more complex than HTTP/2, and there's a lot of code necessary to make it work. I've been using and deploying lucas-clemente/quic-go for a couple years now (in Caddy, so we're already seeing a lot of experimental production deployments) -- frankly it's a beast. What's the benefit of having it in the standard library right now?

It's OK if it's not in the standard library right away. I'd rather the standard implementation be correct, elegant, and stable, true to the reputation of the Go standard library.

[ShivanshVij]

I understand what you’re saying, but the issue is that the NodeJS team had been experimenting with Quic support for months before this release.

Now that companies like Cloudflare and Google are beginning support, it’s unlikely that the IETF standard will change drastically.

There’s no reason not to begin implementation or at least experimentation and make whatever small tweaks are necessary for the general availability release once the standard is completed by IETF.

[ShivanshVij]

@mholt is completely correct in saying that whatever finalized HTTP/3 library is released should be elegant and stable. However, what I am saying is that I believe that we should at least begin an in-depth discussion on the topic instead of just saying we will wait for the standard to be completed by IETF.

If we leave it until later, then I can see an issue where people will want to use the vast benefits of HTTP/3 but be unable to do so with Golang. (This is the main reason I have to write my server code in NodeJS right now, HTTP/3 is a requirement for us)

[makeworld-the-better-one]

Google has been using and pushing HTTP/3 since before it was even called that, they deployed their super-experimental non-standardized original version of the protocol in Chrome as early as 2012. It is not surprising they are still using and pushing it now, while it is still not standardized. I would argue Cloudflare is also supporting it prematurely, likely to test their implementation at scale.

No browser currently supports HTTP/3 by default. See https://caniuse.com/http3

However, what I am saying is that I believe that we should at least begin an in-depth discussion on the topic instead of just saying we will wait for the standard to be completed by IETF.

I agree that beginning discussion would be helpful. I'm just saying I understand why it hasn't happened yet, and I think there is still plenty of time. The current usage and demand for HTTP/3 seems to be effectively zero.

This is the main reason I have to write my server code in NodeJS right now, HTTP/3 is a requirement for us

Why not use quic-go?

[pofl]

As I see it, QUIC and HTTP/3 are so far into the IETF process that they are hardly bound to change anymore, definitely not substantially. Let me argue that if somebody would start implementing now they will not have to throw away any part of the implementation due to changes to the standard. By lying in wait for the finalization Go is only perpetuating the chicken-and-egg problem.

Not that any of this is a problem. Just my two cents.

[FireMasterK]

Has there been any progress on bringing an official implementation? Is there any issue that is blocking this?

I can't seem to understand what's blocking this, there seems to be a lot of interest too. Sure, quic-go does the job, but I'm sure it's nice to have official support for quic.

[awnumar]

Overview of HTTP/3 support amongst clients and servers: https://daniel.haxx.se/blog/2021/04/02/where-is-http-3-right-now/

tldr: the level of HTTP/3 support in servers are surprisingly high considering very few clients enable it by default yet.

I assume that the rest of the browsers will also enable HTTP/3 by default soon, and the specs will be released not too long into the future. That will make HTTP/3 traffic on the web increase significantly.

The TLS library situation will continue to hamper wider adoption among non-browsers and smaller players.

[awnumar]

A few more browsers support it now: https://caniuse.com/http3

[nirui]

Guys, guys, something to read about:

• https://groups.google.com/g/golang-codereviews/c/4ZLaf11dB6I?pli=1
• https://go-review.googlesource.com/c/net/+/301454

[schoenenberg]

QUIC has been published by the IETF as RFC 9000!

See this post: QUIC is now RFC 9000

HN Discussion: https://news.ycombinator.com/item?id=27310349

[DeedleFake]

Note that that does not include HTTP/3. That'll be a separate RFC later on. I do think that this shows that it's about time to get an official QUIC implementation, though, either directly in net or in something like net/quic. If it starts in golang.org/x/net/quic first, that's fine, too.

[seankhliao]

Quic is #44886

[aojea]

I think it's clear that Go must support HTTP/3

@ianlancetaylor is it fair to assume that in a future if I do:

resp, err := http.Get("https://example.com/")

can I be using UDP underneath?

The context is about code that use the golang net/http library to implement HTTP/s probes, my understanding is that golang will probably end defaulting to http3, as it happened with http2, so, it will not be safe to assume http == TCP using net/http

[ianlancetaylor]

@aojea I don't know anything about the code you mention, so I don't know whether it matters, but, yes, I agree that in the future it will not be safe to assume that the net/http package uses TCP underneath.

[alexec]

Yes please to this! Very exciting!

[karelbilek]

Hello.

Sorry if I am being annoying. Is Go team planning to implement http3 (and therefore quic) client/server in go library and is there some sort of timeline?

Or is go team first waiting for the draft to be finalized? Currently, there is already support in browsers (including Google's own Chrome) based on that draft.

Thanks.

[awnumar]

is there any progress？

These useless comments ping everyone who is subscribed to this thread. Stop with the spam

[lemon-mint]

Now HTTP/3 is standardized

https://www.rfc-editor.org/rfc/rfc9114.html

[thomasf]

That document has the "Proposed standard" state and not "Internet Standard" but it is on the more stable side of the standardization process now.

• Definition of proposed standard: https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.1
• Definition of internet standard: https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.3

[mnordhoff]

For that matter, HTTP/2 is also a Proposed Standard.