RE: Streams after receiving GOAWAY

This was discussed a while ago on-list.  The server wants to stop the client from initiating new streams (the first GOAWAY) without killing requests that it may already have in flight.  The server will send a subsequent GOAWAY informing the client of the actual last stream processed.  This is behavior by a server that wants to be less strict – that doesn’t mean clients should abuse it.

There was discussion of an extension to define a DRAINING frame or setting, which is a hint to the client that a GOAWAY will be coming soon, so it may want to spin up a failover connection.  That extension was never actually defined, but if you have a use case in which it would help, write a draft….

From: Patrick McManus [mailto:pmcmanus@mozilla.com]
Sent: Sunday, November 15, 2015 7:47 AM
To: Glen Knowles <gknowles@ieee.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Streams after receiving GOAWAY


On Sun, Nov 15, 2015 at 5:24 AM, Glen Knowles <gknowles@ieee.org<mailto:gknowles@ieee.org>> wrote:
When my server wants to close a connection it sends a GOAWAY with last stream id set to a value somewhat higher than anything it has received. It then keeps the connection until the reported last id is reached or enough time goes by.

That's a bug for your server. When you send GoAway(last=N) as a server, the client knows that streams >N can be safely replayed in another session - they were not accepted by the server. When you send GoAway(last=N+C) (with C as a buffer) and you continue to process some but not all of C based on "enough time going by" the client loses this information.. So that will lead to interop bugs and unsafe behavior.
If you're interested in breaking the connections for reasons of idle, this shouldn't be an issue. If you're interested in migrating load gracefully then you might take a look at alt-svc which is meant to cover that case by setting up an alternative connection asynchronously.

hth
-P