Description

Not an issue, yet, but I think the upcoming QUIC implementation won't work in the browser.

@thinkerou, @appleboy Have you tested it in the browser? I believe you will need to use http3.ListenAndServeTLS instead of http3.ListenAndServeQuic here: https://github.com/gin-gonic/gin/blob/24d67647cb9b4e0bbdcdec7f0c2086e8004e1572/gin.go#L572

The reason is the server first needs to advertise the QUIC support over TCP, apparently. The issue was discussed here: https://github.com/quic-go/quic-go/issues/3890

I have made a few tests of your code and some own implementation and came across this issue.

Expectations

Browser connects

Actual result

Browser does not connect with NS_ERROR_CONNECTION_REFUSED

Environment

  • go version: 1.22.3
  • gin version (or commit ref): 3ac729dc4a497d360a23b9d7e766c622b3c99f51
  • operating system: windows

Comment From: wangshiben

I also meet this problem, QUIC protocol will not take effect in the Chrome browser's core. But you can test it in firefox core.And I also made a framework to support quic server(as high-performance as Gin, or even faster, and also support http1.0 to http 2.0).

QuicFrameWork

Test Documentation

Comment From: aitay721822

It is possible to use goroutines to simultaneously serve both HTTP/2 and QUIC servers, while also setting the ALT-SVC header in the HTTP/2 server.

I recently learned that DNS SVCB records can be used to discover QUIC servers, so a TCP connection might not be necessary I think

Comment From: bneigher

Is RunQUIC still something that is being considered?