go: net/http: cannot set custom/special pseudo-headers when using HTTP/2
What version of Go are you using (go version)?
$ go version go version go1.12.5 linux/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GOARCH="amd64" GOBIN="" GOCACHE="/home/jadenw/.cache/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOOS="linux" GOPATH="/home/jadenw/go" GOPROXY="" GORACE="" GOROOT="/usr/lib/go" GOTMPDIR="" GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64" GCCGO="gccgo" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build648789117=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I attempted to implement websockets over HTTP/2, AKA RFC 8441, with net/http.
What did you expect to see?
Some mechanism of setting :protocol as defined in section 5 of RFC 8441.
What did you see instead?
There is no way to specify extra pseudo-headers in a request with net/http, at least that I can find in the header encoding code.
I am really not sure what the best way to solve this would be, or whether it is fully worthwhile. However, I would really like to be able to use a user-provided *http.Client for this, and this is the only thing I have not yet found a workaround for.
Clarification: pseudo-headers do not satisfy httpguts.ValidHeaderFieldName and therefore cannot be passed in with the regular headers
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 7
- Comments: 17 (14 by maintainers)
Are there some plans to add the support in the next time?
We are trying to enable http/2 at our cloud foundry environment and noticed that the gorouter cannot handle http/2 websockets. I also opend issue https://github.com/cloudfoundry/routing-release/issues/230.
Chrome as a client is also supporting it in the meantime https://www.chromestatus.com/feature/6251293127475200 this would lead into connection problems.
@bradfitz how about we automatically convert HTTP/1.1 Upgrade requests into HTTP/2 if the peer supports it in *http.Transport? We’d have to perform an initial HTTP/2 request on the endpoint to check if it supports RFC 8441, cache that and then from there we can automatically decide whether or not to do HTTP/1.1 or HTTP/2 for subsequent upgrades.
Would mean my WebSocket library basically gets client side HTTP/2 WebSockets for free and httputil.ReverseProxy can proxy RFC 8441 connect requests.
@jadr2ddude, thank you for filing this issue! As @nhooyr mentioned, so if you are implementing Websockets I believe the first step that you want to do is to hijack the connection and then if you know you are using HTTP/2, you can use the golang.org/x/net/http2 package to create the framer and send over the respective headers by yourself. IMHO we shouldn’t be changing net/http to make that change here. Please feel free to reopen though if I’ve missed something, thank you!
@bradfitz I’d like to prepare some CLs for this in the coming weeks, could you please review my proposal above?
My apologies @jadr2ddude @mikedanese @nhooyr for the brainless close and non-responsiveness for the correction, I posted my response right before a long dinner. Thanks for reopening it, Brad!