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

Jump to bottom

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

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

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

gopherbot opened this issue Sep 30, 2014 · 4 comments
Labels
FrozenDueToAge
Milestone
Go1.5

Comments

@gopherbot
Copy link

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
Copy link
Contributor

Comment 1:

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

@gopherbot
Copy link
Author

Comment 2 by bgmerrell:

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

@gopherbot
Copy link
Author

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.

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@rsc rsc removed the repo-main label Apr 14, 2015
@gopherbot
Copy link
Author

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

@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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.5
Development

No branches or pull requests
4 participants
@bradfitz @rsc @ianlancetaylor @gopherbot