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: client fails to detect Connection: close header in an edge case #8840

Closed
gopherbot opened this issue Sep 30, 2014 · 4 comments

Comments

Projects
None yet
4 participants
@gopherbot
Copy link

commented Sep 30, 2014

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

This comment has been minimized.

Copy link
Contributor

commented Sep 30, 2014

Comment 1:

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

@gopherbot

This comment has been minimized.

Copy link
Author

commented Oct 8, 2014

Comment 2 by bgmerrell:

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

This comment has been minimized.

Copy link
Author

commented Oct 8, 2014

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 gopherbot added new labels Oct 8, 2014

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014

@rsc rsc removed the repo-main label Apr 14, 2015

@gopherbot

This comment has been minimized.

Copy link
Author

commented Apr 28, 2015

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

@bradfitz bradfitz closed this in ae080c1 Apr 29, 2015

@golang golang locked and limited conversation to collaborators Jun 25, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.