Comment 2 by zarcardfly:

Step 1,2,3 the server respond with specified Content-Length, Step 4 the server respond
with chunked semantic.
In either case we  have the approach to check a half-baked read.
For first case, a half-baked read is detected when the total readed bytes is less than
Content-Length, but can't read anymore(Read return 0, nil).
For second case, a half-baked read is detected when the trailer is missed, but can't
read anymore.
Tell me if I misunderstand something, thank you.
It seems my previous comment was missed, so I send it again. It it's reduplicative,
please ignore it

Comment 3:

Labels changed: added priority-later, removed priority-triage.

Owner changed to @bradfitz.

Status changed to Accepted.

Comment 4:

Changed summary.
The bug is that the HTTP client (type *http.Transport) gets an HTTP response from the
server saying "Content-Length: 400000" and then proceeds to get reads:
2013/06/21 10:58:46 Read = 633, <nil>
2013/06/21 10:58:47 Read = 8192, <nil>
2013/06/21 10:58:47 Read = 8192, <nil>
2013/06/21 10:58:47 Read = 8192, <nil>
2013/06/21 10:58:47 Read = 8192, <nil>
2013/06/21 10:58:48 Read = 8192, <nil>
2013/06/21 10:58:48 Read = 8192, <nil>
We then kill the server, which closes the TCP connection, and the client receives:
2013/06/21 10:58:52 Read = 0, EOF
But because we're not de-chunking, we see (0, EOF) from the TCPConn and we assume that's
just the end of the body and pass that through.
We already do count to make sure we don't over-read past the declared Content-Length
(with an io.LimitReader), but don't count that we under-read.
We should return an io.ErrUnexpectedEOF when we see EOF from the server and we haven't
gotten all the bytes.

Comment 5:

Mailed https://golang.org/cl/10237050/

Status changed to Started.

Comment 6:

This issue was closed by revision a054028.

Status changed to Fixed.

Comment 7:

Is this worthy of Go 1.1.x?

Comment 8:

Brad: add this fix to 1.1.2 (if there is one) or not?  Your call.

Comment 9:

The reason I ask: we've massive increased our use of net/http in client and server code
in the past few months, and we'd usually be happy to get this fix from tip, but due to
the current state of the runtime, we've had to hold at 1.1.x.

Comment 10:

While a safe fix, this bug has existed from day 1.  It wasn't urgent the past few years,
so it's probably not urgent for 1.1.2.
There isn't a work-around, though.
I'm neutral on 1.1.2.
fullung, worst case, if you're actually hitting this problem, you could cherry-pick it
into your local build.

Comment 11:

I'm inclined to leave this out of 1.1.2. We've been burned before by
changing net/http semantics in a bug fix release without realizing it.

Comment 12:

I agree.