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):

• dedicated raw quic protocol API, just as tcp/udp?
• http/3 server to be used explicitly and can be supported implicitly with http/2 as fallback using port reuse from a different API?

[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

[LOVELiberty6699]

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.

As far as I know，there are some different between HTTP/3 and IETF QUIC. HTTP/3 is an Application Layer Protocol, but IETF QUIC is a Transport Protocol. TCP, UDP and iQUIC are in the same layer. IETF QUIC can replace TCP, so one day every Protocol based on TCP be able to work based on IETF QUIC, such as SSH. HTTP/3 is based on IETF QUIC. So I think that the support of HTTP/3 is not root. We should add the support of IETF QUIC firstly, and then add the support of HTTP/3.
HTTP/2 and HTTP/3 work in a similar way, but HTTP/2 uses TCP,
while HTTP/3 uses IETF QUIC as the transport protocol. HTTP/3 support is optional. When enabled, HTTP/3 can fall back to HTTP/2 or HTTPS if not available.
So should we need to make some modification on this issue or reopening a new issue to track IETF QUIC?

[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.