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

net/http: If the response is returned directly and the request body is not consumed, the browser throws an error, but nodejs does not. #62694

Closed
tianluanchen opened this issue Sep 18, 2023 · 2 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@tianluanchen
Copy link

tianluanchen commented Sep 18, 2023

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

$ go version
go version go1.20.2 windows/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
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\Administrator\AppData\Local\go-build
set GOENV=C:\Users\Administrator\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\Administrator\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\Administrator\go
set GOPRIVATE=
set GOPROXY=https://goproxy.cn
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20.2
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\ADMINI~1\AppData\Local\Temp\go-build2456021619=/tmp/go-build -gno-record-gcc-switches

What did you do?

When sending data to an HTTP server built in Go, the browser throw a network error if the server returns a response without actively consuming the request body (only if the request body is large). However, this error does not occur when using an HTTP server built with Node.js.

example
https://github.com/tianluanchen/go-issue-62694

What did you expect to see?

No error occurs in the browser

What did you see instead?

The browser throws a network error

@bcmills
Copy link
Contributor

bcmills commented Sep 18, 2023

This seems related to #3595.

If the server doesn't read the complete request, there is a race inherent in the HTTP protocol: see RFC 7230 §6.6, starting with the paragraph that begins “If a server performs an immediate close of a TCP connection”.

As far as I can tell, there is no way to avoid that race without also requiring the server to read the entire request, which would allow a misbehaving client to consume a proportionally very large fraction of the server's incoming bandwidth. Instead, the Go HTTP server implementation waits for an arbitrary delay that is usually long enough. Perhaps in your case that arbitrary delay is too short.

If you are not worried about ill-behaved clients, you could have your server Flush its response to the client (to minimize latency) and then io.Copy(io.Discard, req.Body) before returning.

(CC @neild)

@bcmills bcmills added Unfortunate NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Sep 18, 2023
@tianluanchen
Copy link
Author

This seems related to #3595.

If the server doesn't read the complete request, there is a race inherent in the HTTP protocol: see RFC 7230 §6.6, starting with the paragraph that begins “If a server performs an immediate close of a TCP connection”.

As far as I can tell, there is no way to avoid that race without also requiring the server to read the entire request, which would allow a misbehaving client to consume a proportionally very large fraction of the server's incoming bandwidth. Instead, the Go HTTP server implementation waits for an arbitrary delay that is usually long enough. Perhaps in your case that arbitrary delay is too short.

If you are not worried about ill-behaved clients, you could have your server Flush its response to the client (to minimize latency) and then io.Copy(io.Discard, req.Body) before returning.

(CC @neild)

Thanks for your help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Unfortunate WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

2 participants