-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/net/http2: support proxying udp in HTTP/2 with RFC 9298 #67860
Comments
An update, turns out if i use any other method besides "CONNECT", i can have a UDP connection with just the headers
But this might just work for my particular case. Since RFC expects UDP connection to work on CONNECT method. |
CC @neild |
I'm sorry, but I don't understand what the specific request is here. Are you implementing RFC 9298, or are you hoping for some part of net/http to support it directly? An obstacle to implementing RFC 9298 over HTTP/2 using net/http is that we currently lack support for Extended CONNECT (RFC 8441). There's an accepted proposal to add Extended CONNECT support (#53208), but it has not yet been implemented. |
Similar Issues
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
Yeah, I was expecting RFC 9298 to be supported here. I understand different implementations for HTTP2 UDP tunneling seems to follow different standards. For my use case, I used "CONNECT-UDP", that added the required two header, ":scheme" and ":path", and the proxy server decided to use UDP tunneling for now. RFC 9298 expected me to use "CONNECT", this was my confusion. |
Go version
go version go1.21.1 darwin/amd64
Output of
go env
in your module/workspace:What did you do?
I tried to create a UDP connection through HTTP2 protocol. For HTTP2 connection, the RFC suggests to use
CONNECT
method with following headersI do not see see
protocol
,scheme
andpath
header being set. TheencodeHeaders
method only setsscheme
andpath
, when nonCONNECT
method is being used.RFC doc link: https://datatracker.ietf.org/doc/rfc9298/
What did you see happen?
The server decided to use TCP protocol instead of UDP.
What did you expect to see?
I expected to see UDP connection.
The text was updated successfully, but these errors were encountered: