-
Notifications
You must be signed in to change notification settings - Fork 18k
net/http: ServeContent()/ServeFile() doesn't return expected response when WriteTimeout happens #43822
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
Comments
We have bothered by this bug for a long time. After dig into code I found that when I think we should invoke go/src/internal/poll/sendfile_linux.go Line 20 in ecf4ebf
|
Maybe the patch of " w.cw.flush() " is better, when the Head failed to send , shoud just cancel whole respose procedure,for a body withoud Head is malformed of HTTP protocal at all。 |
Change https://golang.org/cl/285914 mentions this issue: |
@dmitshur @toothrot @cagedmantis This issue might be worthy of a backport, so we may want to consider adding CL 285914 to 1.16 even though rc1 is out. I'd like @neild to take a look at the test, though. Thanks. |
Roger that, I've added feedback to improve the test :-) |
@odeke-em, Thanks! I updated it and please take a look. Thank you~ |
As per the comment by Ian in #43822 (comment), this issue is a worthy candidate. @gopherbot please backport this issue. |
Backport issue(s) opened: #44293 (for 1.14), #44294 (for 1.15). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases. |
Change https://golang.org/cl/296530 mentions this issue: |
In net/http package, the ServeContent/ServeFile doesn't check the I/O timeout error from chunkWriter or *net.TCPConn, which means that both HTTP status and headers might be missing when WriteTimeout happens. If the poll.SendFile() doesn't check the *poll.FD state before sending data, the client will only receive the response body with status and report "malformed http response/status code". This patch is to enable netpollcheckerr before sendfile, which should align with normal *poll.FD.Write() and Splice(). For #43822 Fixes #44294 Change-Id: I32517e3f261bab883a58b577b813ef189214b954 Reviewed-on: https://go-review.googlesource.com/c/go/+/285914 Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Emmanuel Odeke <emmanuel@orijtech.com> Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com> (cherry picked from commit f0d23c9) Reviewed-on: https://go-review.googlesource.com/c/go/+/296530 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
YES
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
We are running simple proxy for retrieving blob files. Just in case, we set
WriteTimeout
for proxy server. The logic is described by the following code.If the handler takes time and the
WriteTimeout
happens, thehttp.ServeFile
still can sends the data without HTTP Status line and header. We use the following code as client to reproduce the issue.The result is like:
Go HTTP Server will call
SetWriteDeadline()
in readRequest. When we callhttp.ServeContent/ServeFile
to write response, the go runtime will use (*response).ReadFrom to make it fast.But we found that the
chunkWriter.flush
doesn't return error so that theReadFrom
doesn't know if the flush works.In this case, both the status and the header are lost because netpoll checker return
I/O timeout
. But the server still send data to client and the data is not valid http response, calledmalformed HTTP status
. TheWriteTimeout
doesn't work well inServeContent/ServeFile
mode and return confusing response. I think it should be aligned with normal mode, described by the following code.What did you expect to see?
I expected to see
EOF
errorWhat did you see instead?
I saw that
malformed HTTP status
.cc @zhuangqh @Ace-Tang
The text was updated successfully, but these errors were encountered: