Skip to content
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

Jump to bottom

net/http: Client hangs forever on 101 Status Code #44988

Open
melardev opened this issue Mar 13, 2021 · 7 comments
Open

net/http: Client hangs forever on 101 Status Code #44988

melardev opened this issue Mar 13, 2021 · 7 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@melardev
Copy link

melardev commented Mar 13, 2021 •
edited

What version of Go are you using (go version)?

$ go version
go version go1.15.8 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
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/laro/.cache/go-build"
GOENV="/home/laro/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/laro/Desktop/SSDStorage/workspace/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/laro/Desktop/SSDStorage/workspace/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
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-build584567735=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I ran the following script locally, it takes forever, do not run that script on the playground because it may be killed by the sandbox as it takes forever.
https://play.golang.org/p/oUNf5aEleAr

What did you expect to see?

Timeout arguments to be enforced.

What did you see instead?

It takes forever.

IMPORTANT

About my title, well... I am not sure, somebody(Jorik) on gophers.slack.com noticed that the server was replying with a 101 status code on Firefox, not sure if that's the reason, in Chrome we don't get such 101 HTTP status, it just hangs. I don't know if httpClient gets such 101 status, all I know is it hangs, so if the reason is 101 Status code, then the title is appropriate, otherwise the title is misleading.

Update

A user(Nils Preuschoff) in that slack channel pointed me at a modified snippet:
https://play.golang.org/p/FPb2i0h--z6

It proves that indeed the faulty behaviour happens on Status Code 101, showing the HTTP status code 101 is the last event prior to hanging on ioutil.ReadAll(), is this a bug on Go? I am setting the timeout on both, header and response body, it should be honored, right?

Update2

Here I attach the equivalent fasthttp snippet doing a request to the same host, I used the default timeout settings from fasthttp to keep it simple, fasthttp, same as http package, has defaults timeouts values greater than 0 (no timeout), fasthttp returns immediately, while the http package hangs forever ...
https://play.golang.org/p/lq8FkgP7oJp
@AlexRouSg
Copy link
Contributor

Go's http client handles http 101 and upgrades the connection to TCP/websocket.
The transport timeouts do not apply when blocking on reading the response.Body cause it is no longer using the http protocol by the time http.Get returns.

@melardev
Copy link
Author

@AlexRouSg So the best is to hang? if it is no longer http protocol why not returning an error? the consequence of your statement is: all Go http clients, are vulnerable to DoS if the server (or someone poisoning the HTTP response) returns 101 status code, is that really what you meant?
Still not convinced, the transport should be able to read a valid HTTP response in less than the configured timeout, that' all I can think as valid behaviour, if it can not read an HTTP response at that time it should return an error, indeed I have seen go HTTP clients returning an error if the server replied with something other than HTTP response, why here should the go client be unresponsive forever? what makes does it make?

@Weneg
Copy link

Weneg commented Mar 13, 2021

According to https://golang.org/pkg/net/http/#Client the timeout should include reading the body of the response

@mdlayher mdlayher changed the title Go HTTP Client hangs forever on 101 Status Code net/http: Client hangs forever on 101 Status Code Mar 14, 2021
@neild
Copy link
Contributor

neild commented Mar 14, 2021

At the very least, if a 101 Switching Protocols response disables the timeout that should be documented.

@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 15, 2021
@cherrymui cherrymui added this to the Backlog milestone Mar 15, 2021
@networkimprov
Copy link

cc @bradfitz @empijei @tombergan @fraenkel

@bradfitz
Copy link
Contributor

bradfitz commented Apr 2, 2021

Maybe the Transport could return an error if it sees a 101 response code to a request that lacked an Upgrade header. That wouldn't break existing websockets clients and I think might even be required to get a 101 response anyway.

@kurimi1
Copy link

kurimi1 commented Feb 24, 2023

same issue. If the server doesn't send anything, the client hangs forever, and the program never exit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
8 participants
@bradfitz @neild @networkimprov @Weneg @AlexRouSg @cherrymui @melardev @kurimi1