Re: GOAWAY clarification

...and I've drawn some pictures:
https://docs.google.com/presentation/d/1yGLlIUqwVy3WeVv8K9HHOSkBietWTjJPlI_pA5wqU-Q/edit?usp=sharing

On consideration, this is a technical change, albeit one that arises
out of clarifying what was previously ambiguous.  I will take the
advice of the working group on how to proceed.

On 22 March 2015 at 08:51, Martin Thomson <martin.thomson@gmail.com> wrote:
> 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:
>
> https://github.com/http2/http2-spec/pull/733
>
> 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 <martin.thomson@gmail.com> wrote:
>> On 21 March 2015 at 09:35, Martin Thomson <martin.thomson@gmail.com> 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.  https://github.com/http2/http2-spec/pull/732
>>
>> 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 16:19:33 UTC