Re: GOAWAY clarification

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.

On 21 March 2015 at 00:12, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 21/03/2015 6:53 p.m., Martin Thomson wrote:
>> This seems right to me...
>>
>> @ https://github.com/http2/http2-spec/issues/731
>> ---
>> We are working on a HTTP/2 library and we are a bit confused and we
>> would like to get it right. That's why I am kindly asking for you to
>> answer the following question:
>>
>> Is it correct that after a sender sent a GOAWAY frame with some last
>> stream identifier to a receiver, the sender may still open new
>> streams, even with stream identifiers higher than the last stream
>> identifier sent in the GOAWAY frame? That is the GOAWAY frame and the
>> last stream identifier only limit the ability of the receiver?
>>
>> If this is correct, and I believe it is, then the I find the following
>> sentence in the first paragraph at 6.8 GOAWAY confusing.
>>
>>     Once sent, the sender will ignore frames sent on any new streams
>> with identifiers higher than the included last stream identifier.
>>
>
> Translation: "go away, Im ignoring *all* future streams after N"
>
>> In my opinion it should say something of the like
>>
>>     Once sent, the sender will ignore frames sent on any new streams
>> created by the receiver with identifiers higher than the included last
>> stream identifier.
>
> Translation: "I am going to ignore you now while I continue making new
> streams to fill your pipe ..."
>
> The behaviour is very different and IMHO the proposal allows senders to
> violate the intent of the GOAWAY.
>
>>
>> Thank you very much!
>> ---
>>
>> After all, the purpose is to create a synchronization point for
>> streams created by a peer, marking some set of them as safe to retry.
>> There is little value in delineating streams created by the sender of
>> GOAWAY.
>
> Yes, however one must take into account what type of action the
> synchronisation was done for / is signalling.
>
> Its pretty clear that the intent of the GOAWAY is to signal connection
> closure gracefully. There is no sense in starting new streams after
> having told the other end you are about to *terminate the connection*.
>
>>
>> That has some ramifications, that I'm sure everyone is already aware
>> of: a server that has decided to process a client frame might
>> reasonably initiate server push after sending GOAWAY.  Equally, a
>> client might hang around after GOAWAY and even make more requests, but
>> server pushes would be "ignored".
>
> Currently its a "might" not "must".
>
> If the proposed alteration happens it becomes a must, because until the
> sender of GOAWAY actually completes sending the last possible stream-ID
> from the full set of 2^32-1, the recipient of GOAWAY cant be sure its
> not going to try sending "just one more".
>
>
>>
>> Of course, given that interpretation GOAWAY from a client could be
>> seen as equivalent to SETTINGS_ENABLE_PUSH=0, depending on the value
>> of the last stream ID provided, that is.
>>
>> I'm not sure that these are new ramifications.  The question is
>> whether we want to somehow prevent any aspect of this interpretation.
>> At this extremely late stage in the process that would require
>> something extraordinary, but I offer the opportunity nonetheless.
>>
>
> If a PUSH_PROMISE was sent *before* sending GOAWAY, then the sender is
> free to complete it under the existing semantics.
>
> If it was sent *after* the GOAWAY then the remote end is already in the
> process of discarding state and terminating the connection. There is no
> guarantee that any of it will be handled, so why would a sane sender
> bother wasting bandwidth on new streams it can expect to be dropped?
>
>
> Amos
>

Received on Saturday, 21 March 2015 16:36:12 UTC