Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: "use of closed network connection" error when reading 1MB or so #21760
What version of Go are you using (
I read the code find that the "use of closed network connection" error reason is, when net/http write request body to server, it read response from server at the same time with the same tcp connection.
In your test case, the server first flush that lead to
So in this test case, client sent body using a "chunked" encoding. so the right output maybe:
So the golang has a bug that it not send "chunked" end message when sees error of 'failReader'.
It sounds like you believe net/http is violating RFC 2616. Can you explain why? I don't see a violation. When Request.Body.Read returns an error, we close the connection, which is allowed. The quoted passage from the RFC says that a client "MAY" send a zero length chunk to prematurely mark the end of the message. This is a MAY. We're not forced to, and in fact, we don't want to because doing so might result in the server incorrectly believing that we have sent the full message.
This is simply a poor error message: We make an effort to prefer the error from Request.Body.Read (see link below), but this effort works only when the Request.Body.Read error happens before the server sends a response. Once the server sends a response, RoundTrip returns and the caller starts reading Response.Body, and the Request.Body.Read error is not propagated to Response.Body.Read.
As evidence for this: When the read limit is low, we get "look at my cool error" from http.DefaultClient.Do. When the read limit is high, we get "use of closed network connection" from io.Copy(buf, resp.Body).
referenced this issue
Nov 1, 2017
What is the request here?
To make Transport.RoundTrip prefer the Request.Body.Read error over the server conn read failure?
The ~million bytes is probably because HTTP/1 servers try to consume their input before replying with any headers. (So the Flush is blocking, reading from the client).
There's also a bug open somewhere to support bidirectional HTTP/1 like HTTP/2's always bidirectional support. (But HTTP/1 would probably need to be opt-in, not on by default).