W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: GOAWAY clarification

From: Martin Thomson <martin.thomson@gmail.com>
Date: Sun, 22 Mar 2015 09:19:07 -0700
Message-ID: <CABkgnnWQaFMnA9AR5v1n6s+x0=UdhRu2j9KmiQoOjhvgQNkvzA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
...and I've drawn some pictures:

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC