RE: GOAWAY clarification

I'm fine with the clarification that the sender of GOAWAY may have initiated streams with a higher stream ID than the recipient of GOAWAY, and the "will ignore" only applies to the recipient-initiated streams.  I think that was always implicit, and I'm happy to make it explicit.

On the other hand, I'm still inclined to see MUST NOT create new streams as the intent of GOAWAY.  The two-phase approach was introduced as an allowance for streams the client may have already initiated, but the client still MUST stop initiating upon receipt of the GOAWAY.  Now, the reality is that the server can't actually tell for sure when the client stopped initiating new streams, so a non-compliant client could keep initiating up to the number that was actually in the GOAWAY frame and hope the server doesn't catch it.  This change just makes that particular misbehavior permitted, which doesn't seem like a net improvement to me.  If the server told the client to stop, the client should stop.

I don't think that's in contradiction to the guidance below, since the first GOAWAY tells the client to stop initiating, and the second GOAWAY confirms the last already-in-flight stream that the server chose to service.  I had not understood the two-phase approach to intend the client to keep sending while it spun up the second connection, and so didn't see the text as inconsistent in that regard.  It sounds like others interpreted the first GOAWAY as a hint that a "real" GOAWAY would follow later, but multiple are allowed.  How does the client know it's finally got the "real" GOAWAY that it needs to obey?

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Sunday, March 22, 2015 9:19 AM
To: HTTP Working Group
Subject: 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 Monday, 23 March 2015 00:17:42 UTC