golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.15k stars 17.56k forks source link

x/net/http2: support proxying udp in HTTP/2 with RFC 9298 #67860

Open Nishan8583 opened 3 months ago

Nishan8583 commented 3 months ago

Go version

go version go1.21.1 darwin/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users/nmaharja/Library/Caches/go-build'
GOENV='/Users/nmaharja/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS='-buildvcs=false'
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/nmaharja/go/pkg/mod'
GONOPROXY='github.office.opendns.com'
GONOSUMDB='github.office.opendns.com'
GOOS='darwin'
GOPATH='/Users/nmaharja/go'
GOPRIVATE='github.office.opendns.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.21.1'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/nmaharja/projects/clean/ProxyConnectTools/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/fv/c8jghnc95_vgn57t5w9hvvlh0000gn/T/go-build1530722529=/tmp/go-build -gno-record-gcc-switches -fno-common'

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 headers

 HEADERS
   :method = CONNECT
   :protocol = connect-udp
   :scheme = https
   :path = /.well-known/masque/udp/192.0.2.6/443/
   :authority = example.org

I do not see see protocol, scheme and path header being set. The encodeHeaders method only sets scheme and path, when non CONNECT 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.

Nishan8583 commented 3 months ago

An update, turns out if i use any other method besides "CONNECT", i can have a UDP connection with just the headers

:scheme = https
:path = /.well-known/masque/udp/192.0.2.6/443/

But this might just work for my particular case. Since RFC expects UDP connection to work on CONNECT method.

mknyszek commented 3 months ago

CC @neild

neild commented 3 months ago

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.

gabyhelp commented 3 months ago

Similar Issues

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Nishan8583 commented 3 months ago

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.

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.