net/http: client fails to detect Connection: close header in an edge case

[gopherbot]

by jim.robinson:

What does 'go version' print?

go version go1.3.2 darwin/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Run http://play.golang.org/p/7m6DwmGGQ9

What happened?

The last request sent by the client fails to establish
a new connection on request# 4.

What should have happened instead?

The client should reconnect to the server instead
of using the closed connection.

Please provide any additional information below.

I ran into this case for real, where a server was sending
back:

HTTP/1.1 200 OK
<other headers>
Connection: keep-alive
<other headers>
Connection: close

and my go based client failed to detect that the server
had closed the connection, causing the next HTTP request
to fail.

My reading of the RFC indicates a server may send multiple
Connect headers, and that if any one of them is a "close"
token, the client should shut down its end of the socket.

It's stupid beyond belief that the server is sending these,
but I think it's technically accepted by the RFC.

[ianlancetaylor]

Comment 1:

Labels changed: added repo-main, release-go1.5.

[gopherbot]

Comment 2 by bgmerrell:

Is this more https://golang.org/issue/4677 ?

[gopherbot]

Comment 3 by jim.robinson:

Solving the problem discussed in 4677 would end up helping this edge case, but I think
the client really ought to be aware of the Connection: close header and handling it. 
It's already trying to, it's just that the current code assumes it just needs to scan
the first Connection header it sees vs. looking across multiple Connection headers for
the first one that specifies close.

[gopherbot]

CL https://golang.org/cl/9434 mentions this issue.