Go’s Official HTTP/3 Proposal: Why Are We Still Waiting?

Introduction

As the next-generation internet protocol, HTTP/3 has garnered significant attention across programming language communities, and its importance cannot be overstated. According to statistics, by early 2025, over 95% of mainstream browsers will support HTTP/3. Approximately 32% of requests on the Cloudflare platform will use HTTP/3, and about 35% of websites globally will publicly declare HTTP/3 support). Given this trend, the Go community has been eagerly awaiting official HTTP/3 support for years.

As early as 2019, developers created a dedicated issue (#32204) to track the progress of Go’s standard library on HTTP/3 support, viewing it as an “inevitable” evolution. This proposal has received nearly 370 👍 reactions from the community, demonstrating strong anticipation among developers. Yet today, Go still hasn’t rolled out official HTTP/3 support. In fact, a recent internal meeting resulted in the temporary shelving of HTTP/3 support.

This article provides an in-depth analysis of Go’s official HTTP/3 proposal, including its history, current status, and the reasons behind the ongoing wait.

Go’s HTTP/3 Absence and QUIC’s Critical Role

Go’s standard library, net/http package, currently provides native support only for HTTP/1, with HTTP/2 support available through golang.org/x/net/http2. (HTTP/2 may soon be added to the official release.) HTTP/3 support remains a blank slate.

Developers wanting to use HTTP/3 in Go must rely on third-party libraries or special proxies. For instance, the well-known Caddy server achieves HTTP/3 support by integrating the open-source quic-go library, but this is ultimately an unofficial solution with certain limitations. As Caddy’s documentation emphasizes: “Go’s standard library hasn’t implemented HTTP/3 yet, so some features may be restricted.” Clearly, the lack of official support means various frameworks and applications in the ecosystem cannot transparently benefit from HTTP/3’s advantages.

HTTP/2’s Limitations:

Why Do We Need HTTP/3?

While HTTP/2 alleviates HTTP/1’s head-of-line blocking through multiplexing, it still relies on TCP transport. When a single TCP packet is lost, all requests and responses on the entire connection are blocked (the infamous head-of-line blocking problem). 
Additionally, HTTP/2 requires complete TCP and TLS handshakes for each new connection, resulting in higher network latency. In high-packet-loss, high-latency network environments, these factors significantly impact performance and user experience.

The key to HTTP/3 lies in its use of the QUIC protocol at the transport layer. QUIC is built on UDP and implements reliable transmission at the application layer, explicitly designed to address TCP’s bottlenecks. With QUIC, HTTP/3 can transmit multiple streams in parallel over a single physical UDP connection, and the loss of individual packets doesn’t block data transmission on other streams, effectively avoiding head-of-line blocking. 
Simultaneously, QUIC combines TLS 1.3 encryption handshakes with connection establishment, dramatically reducing connection latency. For scenarios with poor network conditions (such as mobile networks) or high latency, HTTP/3 can significantly improve transmission efficiency and reliability.

As Go team members have pointed out, QUIC support is a prerequisite for implementing HTTP/3. Without QUIC, there’s no real HTTP/3.

The Go team understands this well. In early 2023, they proposed and accepted a proposal (#58547) to add an experimental QUIC implementation to x/net, explicitly stating that “QUIC is the underlying protocol for HTTP/3, and QUIC support is a necessary precondition for HTTP/3 support.” This proposal subsequently unfolded in the golang.org/x/net/quic repository, providing basic APIs for QUIC connections and streams, giving Go fundamental QUIC capabilities.

However, implementing QUIC is highly complex — RFC 9000 doesn’t specify concrete APIs, leaving each implementation to figure things out independently. The Go team chose to implement a complete QUIC stack from scratch in pure Go, which undoubtedly requires significant time to refine performance and stability.

Current Progress: To date, Go’s experimental QUIC package is partially complete, and an HTTP/3 experimental package built upon it has begun to take shape. According to Go documentation, the golang.org/x/net/internal/http3 package already contains an HTTP/3 implementation, but it’s explicitly marked as “under development, not suitable for production,” with APIs subject to change. This indicates that Go officials have begun exploring HTTP/3 technically, but are not yet ready to release a stable version to the public.

Community Feedback and Proposal Status: Enthusiasm, Anticipation, and Confusion

When Go’s official HTTP/3 proposal (Issue #70914) was formally submitted in late 2024, the community was elated. The proposal suggested adding HTTP/3 client and server implementations to x/net/http3, advancing it experimentally.

However, confusingly, the proposal was quickly tagged with “Proposal-Hold.” In other words, while the proposal itself wasn’t rejected, it was shelved — temporarily not entering the implementation phase. The Go team hasn’t publicly detailed the reasons for the delay, leaving many developers puzzled: It’s 2025, the HTTP/3 standard has been finalized for a long time, browsers and other languages support it enthusiastically — why is Go still holding back?

Based on past information, the Go team’s cautious approach may provide partial answers. First, officials have repeatedly emphasized the need to wait for IETF standards to stabilize before taking action. For example, in early issues related to HTTP/3, the Go team noted that HTTP/3 was still a draft, and implementing it before its final standardization could risk massive refactoring later. This reflects Go team’s pragmatic and steady side: better to move slowly than to “crash and burn.” Only after HTTP/3 (RFC 9114) was officially released in 2022 did Go truly begin implementing QUIC/HTTP3, confirming this caution.

Second, API design complexity is also a factor. Integrating QUIC/H3 into the existing net/httpframework in a developer-friendly manner without compromising compatibility is a challenging problem. The Go team prefers to experiment with mature solutions in the x/net repository before migrating them to the standard library. This process dictates that the timeline won't be aggressive.

Of course, for the community that has waited so long, official silence and slowness remain frustrating. Some community members have frankly expressed dissatisfaction and confusion in discussions, while others joke that “Go has become conservative in network innovation.” However, rational voices also point out that official resources are limited, and implementing QUIC/H3 is highly challenging, requiring patience.

The third-party library quic-go has served as a substitute for a long time, described as “a pure Go QUIC/H3 implementation that has reached production-ready level,” adopted by many projects (such as Caddy mentioned earlier). The Go team may hope to develop a higher-quality official implementation based on community experience.

The proposal’s status currently remains on hold. HTTP/3 is still some distance from being officially added to Go’s standard library. However, it’s worth noting that related experimental development hasn’t actually stopped: code in x/net/internal/http3 continues to evolve and update. The Go team sees the community’s enthusiasm and anxiety. This highly anticipated feature hasn’t been abandoned, but is being refined until the right moment for release.

Comparison with Other Languages: How Are Other Ecosystems Progressing with HTTP/3?

To better understand Go’s progress on HTTP/3 support, let’s compare other mainstream languages and platforms. Various ecosystems have vastly different attitudes toward HTTP/3 — some are running fast, some are cautiously observing, and some are relatively slow like Go. Let’s look at several typical languages:

• Rust: The Rust community has been quite aggressive in embracing new protocols. Thanks to its robust network development ecosystem, even before HTTP/3 standards were finalized, multiple QUIC/HTTP3 implementation libraries emerged in Rust. For example, Mozilla developed the Neqo project, Cloudflare open-sourced the Quiche library, and there are community-led async implementations, such as Quinn, and AWS’s S2N-Quic. 
  These libraries are feature-complete and offer excellent performance, allowing many Rust web frameworks to experiment with HTTP/3 through them. While Rust’s standard library doesn’t directly integrate HTTP/3, thanks to these mature third-party libraries, Rust developers have been able to use QUIC and HTTP/3 in production environments for some time.
• Node.js: Node.js’s HTTP/3 support has progressed relatively slowly. As early as Node.js 15, released in 2020, officials introduced experimental QUIC support as preliminary research for HTTP/3’s transport layer. However, subsequent LTS versions haven’t officially rolled out HTTP/3. As of mid-2024, support requests for HTTP/3 in Node.js remain unresolved, with the corresponding GitHub issue (#38478) still open. In other words, Node.js doesn't yet have built-in HTTP/3 support (requiring proxies or compiling with experimental options). This is somewhat similar to Go—both are mainstream backend platforms still "waiting" for official solutions. However, the good news is that the Node.js core team continues to follow QUIC's maturation, and future Node 20+ versions are expected to provide a stable HTTP/3 implementation.
• Java: Java has officially supported HTTP/3 in JDK 26
• Python: Although Python isn’t renowned for high-speed networking at the lower level, the community’s exploration of HTTP/3 is quite active. Python’s standard library does not yet support HTTP/3 (built-in http.client and common frameworks remain at the HTTP/1.1/2 stage, but the third-party ecosystem is exceptionally active. The most well-known is aioquic — a pure Python QUIC/HTTP3 library that already enables developers to build clients and servers. Based on aioquic, HTTP/3-supporting ASGI servers (like Hypercorn) and HTTP clients (like httpx) have emerged, implemented through optional dependencies. Therefore, in the Python world, although official progress is slow, developers can already experiment with HTTP/3 through community efforts. Of course, given Python’s performance limitations, these attempts are more for functionality verification and lightweight scenarios, with large-scale deployments still rare.

In summary, different languages have varying degrees of HTTP/3 support: some have implemented it early through experimental libraries (Rust, Python).
Meanwhile, languages like Go and Node.js are proceeding cautiously and slowly. It’s worth mentioning that currently, aside from .NET and Java, almost no language has formally integrated HTTP/3 into its standard library, with most relying on extension libraries. This indicates that implementing QUIC/HTTP3 is highly complex — a challenge the entire industry faces together, not just Go falling behind. However, comparatively speaking, Go was once renowned for its “network concurrency,” and now, with its new protocol support appearing somewhat sluggish, some developers are anxious.

Impact on Go’s Future: How Will HTTP/3 Change the Go Ecosystem?

In due time, once Go officially rolls out HTTP/3 support, its significance will be multifaceted, bringing positive impacts to both the Go ecosystem and developer experience:

Network Performance and Capability Enhancement:

Official HTTP/3 support will significantly strengthen Go’s performance in complex network environments. Leveraging QUIC’s characteristics, Go servers and clients will have stronger anti-packet-loss and anti-latency capabilities, such as connection migration, 0-RTT establishment, and multi-path parallel transmission without blocking. These are all built-in advantages of the QUIC protocol. For high-concurrency, cross-regional services, HTTP/3 can reduce page load times and improve request throughput, resulting in tangible improvements to the end-user experience. Additionally, Go’s “shortcoming” in network programming will be addressed, allowing developers to confidently apply Go to scenarios with stricter real-time requirements, such as mobile APIs and IoT communications, without worrying about protocol bottlenecks.

API Transparency and Consistency:

We have reason to believe the Go team will carefully design HTTP/3 integration to make it as transparent and straightforward as possible for developers. Recall when Go introduced HTTP/2 — most applications benefited automatically with almost no code changes, because the Go standard library encapsulated protocol negotiation and upgrades internally. Similarly, future HTTP/3 support is likely to continue this philosophy. 
For example, Go’s http.Client might automatically select HTTP/1.1/2/3 based on server support, while http.Server could simultaneously listen on UDP port 443 to provide H3 service after enabling TLS. This transparent upgrade will significantly lower the barrier to entry for the new protocol, allowing the developers to use HTTP/3 "out of the box" without needing to understand complex, low-level details. Better yet, if implemented well, existing applications using net/http might only require minimal configuration changes to seamlessly enable HTTP/3, maintaining Go's consistently concise development experience.

Protocol Support Forward-Looking Nature

Embracing HTTP/3 also means Go keeps pace with internet protocol evolution, staying modern. HTTP/3 isn’t the endpoint — it has spawned new technologies like WebTransport (implementing low-latency bidirectional communication based on HTTP/3). If Go has a solid HTTP/3 foundation, further supporting technologies like WebTransport will have fertile ground to grow. This is very important for enhancing Go’s competitiveness in cutting-edge fields (such as real-time communication, browser collaboration, etc.). Conversely, if HTTP/3 support is delayed indefinitely, Go might miss opportunity windows for emerging technology waves. Therefore, official HTTP/3 support will place Go on a newer platform, better positioned to expand its network functionality landscape in the future.

Developer Confidence and Experience

Finally, from a community ecosystem perspective, officially filling the HTTP/3 gap will boost developer confidence. Many Go developers have actually been using libraries like quic-go in their projects, but these are temporary solutions with inevitable concerns about compatibility and maintenance. Once officials release built-in HTTP/3 implementation, these worries will vanish. Developers can avoid pitfalls and focus more on business logic, with simpler and more robust implementation and deployment processes. This will undoubtedly further consolidate Go’s position as a “reliable first choice” in backend development. When that time comes, questions about “Go falling behind the times” will collapse on their own. Instead, we’ll see Go continue to excel in high-performance network programming, attracting adoption in more scenarios.

Conclusion

Upon examining the entire process, we observe Go’s cautious yet firm stance on HTTP/3 support. On the one hand, the Go team hasn’t been swept up by community urgency to rush progress; they chose to build a solid foundation (by implementing QUIC first), wait for standard stability, and even prefer to move slowly to ensure a comprehensive solution. This style has previously been criticized for being “slow to act” when introducing features like generics, but ultimately proves that “slow and steady wins the race.” On the other hand, the Go team isn’t stuck in their ways — from the proposal’s submission and experimental package development, we can see they consistently recognize HTTP/3’s significant value, just maintaining prudence on the questions of when and how to add it to the standard library.

“Why are we still waiting?” 
The most straightforward answer is to wait for it to improve. When official HTTP/3 support finally arrives, we believe it will be of high quality and well-integrated, achieving Go’s consistent ease of use and efficiency. At that time, Go will fill this gap, allowing developers to enjoy the benefits of HTTP/3 without hesitation.