net/http: make Server.SetKeepAlivesEnabled(false) drop currently-open connections #9478

Closed
bradfitz opened this Issue Dec 30, 2014 · 9 comments

Projects

None yet

5 participants

@bradfitz
Member

When adjusting the firewall configuration on a GCE instance today, I was confused that I could toggle my new firewall rule and see the changes immediately affect my ability to telnet to the http server, but my browser continued to work fine, regardless of the firewall setting.

What I realized (too slowly) was happening was that once the keep-alive connection was open, the firewall permitted it forever, as designed and documented.

It would be nice of the google.golang.org/cloud/compute/metadata package or similar could listen for metadata changes (the GCE metadata service supports long polling on changes) to see when the firewall or tags change, and then call Server.SetKeepAlivesEnabled(false) to drop existing connections and force them to (try) to reconnect.

Currently Server.SetKeepAlivesEnabled only affects future connections and not active idle ones.

@bradfitz bradfitz added this to the Go1.5Maybe milestone Dec 30, 2014
@rsc
Contributor
rsc commented Jun 29, 2015

Too late for Go 1.5.

@rsc rsc modified the milestone: Unplanned, Go1.5Maybe Jun 29, 2015
@bradfitz
Member

Related: #4674

@tpng
tpng commented May 9, 2016

Any plan on fixing this?
Default support for http2 is included in Go 1.6, and browsers supporting http2 are reusing single connection by design.
Server.SetKeepAlivesEnabled(false) only affecting new connection means there are currently no way to close the only connection opened by browsers gracefully.
We can close the connection using the Server.ConnState hook, but it causes Chrome to display a error page before opening a new connection.
And I don't think we have enough info to send a GOAWAY frame inside the Server.ConnState hook.

@bradfitz bradfitz modified the milestone: Go1.8Maybe, Unplanned May 9, 2016
@quentinmit quentinmit added the NeedsFix label Oct 10, 2016
@rsc
Contributor
rsc commented Oct 20, 2016

@bradfitz, too late for Go 1.8, yes?

@bradfitz
Member

A couple of the other issues might make this easy. I'll close this at the end of the week if it doesn't happen, but let's keep it open until then.

@gopherbot

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

@gopherbot gopherbot pushed a commit that closed this issue Nov 1, 2016
@bradfitz bradfitz net/http: add Server.Close & Server.Shutdown for forced & graceful sh…
…utdown

Also updates x/net/http2 to git rev 541150 for:

   http2: add support for graceful shutdown of Server
   https://golang.org/cl/32412

   http2: make http2.Server access http1's Server via an interface check
   https://golang.org/cl/32417

Fixes #4674
Fixes #9478

Change-Id: I8021a18dee0ef2fe3946ac1776d2b10d3d429052
Reviewed-on: https://go-review.googlesource.com/32329
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
53fc330
@gopherbot gopherbot closed this in 53fc330 Nov 1, 2016
@bradfitz bradfitz reopened this Nov 3, 2016
@bradfitz
Member
bradfitz commented Nov 3, 2016

I'm going to reopen this. The solution I have now is okay, but it's not great. It closes all currently-idle conns, but it should mark all conns for death as soon as they become idle. (For both http1 and http2).

I was thinking this before, but the flaky #17754 really drove it home.

@gopherbot

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

@gopherbot gopherbot pushed a commit that referenced this issue Nov 3, 2016
@bradfitz bradfitz net/http: deflake TestServerSetKeepAlivesEnabledClosesConns
Fixes #17754
Updates #9478 (details in here)

Change-Id: Iae2c1ca05a18ed266b53b2594c22fc57fab33c5e
Reviewed-on: https://go-review.googlesource.com/32587
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
be7c50a
@gopherbot

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

@gopherbot gopherbot pushed a commit that closed this issue Nov 11, 2016
@bradfitz bradfitz net/http: make Server respect shutdown state after handler finishes
If the Server's Shutdown (or SetKeepAlivesEnabled) method was called
while a connection was in a Handler, but after the headers had been
written, the connection was not later closed.

Fixes #9478
Updates #17754 (reverts that workaround)

Change-Id: I65324ab8217373fbb38e12e2b8bffd0a91806072
Reviewed-on: https://go-review.googlesource.com/33141
Reviewed-by: Ian Lance Taylor <iant@golang.org>
9f9d834
@gopherbot gopherbot closed this in 9f9d834 Nov 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment