Why Go’s HTTP/3 Proposal Stalled Again: Inside the Community Debate

Background: Long Wait

Since 2019 the Go community has been eager for HTTP/3 support, opening Issue #32204 to track progress. Although HTTP/3 became an IETF Proposed Standard (RFC 9114) in June 2022 and is now supported by most browsers and many websites, Go’s standard library still lacks native support.

Proposal Content: Seemingly Safe Plan

In 2024 core team member @neild submitted Proposal #70914 to add an experimental HTTP/3 implementation in x/net/http3. The plan mirrors the earlier QUIC proposal #58547:

Develop experimentally in x/net/internal/http3.

After the API stabilises, move it to x/net/http3 for external testing.

Finally submit a formal API review proposal.

Although the approach appears cautious, the proposal was set aside.

Community Discussion: Frustration and Confusion

Issue #32204 shows sustained community interest. The main concerns are:

Third‑party library quic-go has a different maintenance cycle from Go and lacks the backing of the standard library, causing enterprise hesitation.

Integrating HTTP/3 with the existing net/http API is non‑trivial because HTTP/3 runs over QUIC/UDP, requiring different TLS handshake, connection migration, and flow‑control mechanisms.

Go’s strong backward‑compatibility guarantees make designing a seamless API challenging.

The core team’s limited resources are currently focused on moving x/net/http2 into the standard library (see issues #67810, #67816) and polishing HTTP/2, leaving little bandwidth for HTTP/3.

From a pragmatic standpoint, HTTP/2 already satisfies most production needs, and the performance gains of HTTP/3 are not considered critical.

1. API Design Complexity

HTTP/3’s reliance on QUIC means it cannot be added to net/http with a few simple interfaces; deep changes are required to handle UDP‑based connections, TLS 1.3, connection migration, and distinct flow‑control.

2. Backward Compatibility Pressure

Any new API must fit the habits of existing net/http users while exposing HTTP/3 features, a difficult balance given Go’s commitment to compatibility.

3. Resource Allocation Issues

The team is prioritising tasks such as integrating x/net/http2 into the standard library (targeted for Go 1.26) and adding clear‑text HTTP/2 support, which delays work on HTTP/3.

4. Practical Considerations

In many production environments HTTP/2 is sufficient, so the team views HTTP/3 as a lower priority.

Conclusion

Go’s HTTP/3 effort has been repeatedly delayed, reflecting the language’s cautious, “less is more” philosophy. Until the core team allocates more resources, developers will likely continue using the third‑party quic-go library for HTTP/3 support.

Reference Materials

#70914: https://github.com/golang/go/issues/70914

#32204: https://github.com/golang/go/issues/32204

#58547: https://github.com/golang/go/issues/58547

quic-go: https://github.com/quic-go/quic-go

#67814: https://github.com/golang/go/issues/67814

#67810: https://github.com/golang/go/issues/67810

#67816: https://github.com/golang/go/issues/67816