Re: GOAWAY clarification

After sleeping on it, I have taken a more thorough look at the section
and noted a few other inconsistencies.  Thus, I've made a second
proposal that is a little more thorough:

One note regarding this text, since this has already come up on github...

This shouldn't change behaviour.  If you have an implementation that
sends GOAWAY based on the stream identifiers you have seen, then you
are exposed to the "bug" in issue #458, but are otherwise unaffected.
If you implemented the graceful shutdown based on the text produced
for #458; that is, you send two GOAWAY frames, then the only
consequence is that streams might have to be retried by the client.
Ultimately, the choice of last-stream-id will determine how much
allowance is made for imminent transactions.

On 21 March 2015 at 19:27, Martin Thomson <> wrote:
> On 21 March 2015 at 09:35, Martin Thomson <> wrote:
>> It would be easy to deal with your concern by having the receiver of
>> the GOAWAY reply with their own.  I think that avoids all of the
>> problems you indicate.
> So @Scottmitch also notes a further bug here.  We currently prohibit
> the creation of more streams after GOAWAY, which is in direct
> contradiction to the graceful shutdown process.
>     Receivers of a GOAWAY frame MUST NOT open additional
>     streams on the connection, although a new connection can be
>     established for new streams.
> That contradicts the guidance we provide later in the section
> regarding graceful shutdown.  It prevents a seamless transition from
> one connection to another.
> I've created a PR for this.
> I've also taken the liberty of taking a variation on the text from @buchgr.
> I think that this is erratum-worthy, so I'd like to get this in.  But
> I won't do so if there are objections.  If my answer to Amos'
> objection didn't satisfy you (see above; see also the PR text; Amos?)
> then I can remove the second part of the change, but I tend to think
> that it's more consistent with the other fix.

Received on Sunday, 22 March 2015 15:51:30 UTC