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: Keepalive connections are not terminated when server returns. #14927
1. What version of Go are you using?
2. What operating system and processor architecture are you using?
3. What did you do?
Playground Reproduction (must be run locally)
The application creates an HTTP server in a separate goroutine.
This server is then shut down. Everything should be unreferenced by this point. Another server is created in a new goroutine.
It seems that unless there is data written to the ResponseWriter, the old handler functions are used, even for the new server, which has a separate http.ServeMux and http.Server.
It does not matter even if there is minutes between the old server being stopped and the new one being created.
This is not a client specific issue, just so you do not spend time investigating that. This also happens with a browser, which is how the issue was discovered.
4. What did you expect to see?
After server "1" is stopped, there should be no logging lines prefixed with "1", and the handler should always print "yahoo.com".
5. What did you see instead?
Since everything is created "cleanly" in the goroutine AFAICT, there should not be any was for server "1" handler functions to be used.
referenced this issue
Mar 23, 2016
Looks like this is caused by connection pooling. I adjusted your sleep to 30s so I could run netstat. You can see that the listening socket is closed, but there are still connections open to the server which will get re-used to that server process.
It would be nice to close all existing connections after
@klauspost yes the
I had a look through the net and net/http code and I can't see a way to do the equivalent on the server side.
However I think that
The confusion in your repro is that you thought your
ok, since this is now linked to the other cases, I will close this.
It was quite unexpected behavior for me - and from #9478 I can see for you as well. We should maybe add some documentation, that this is the current behaviour - SetKeepAlivesEnabled isn't very clear, and the rest of the http.Server documetation doesn't mention it either.