Re: What are the semantics of a client sent GOAWAY?

I agree with Corey.

> Am 23.05.2019 um 16:52 schrieb Cory Benfield <cory@lukasa.co.uk>:
> 
> My reading of this is that RFC 7540 pretty clearly specifies the
> semantics of client-sent GOAWAY, and that it matches your
> understanding Alan.
> 
> Section 5.1.1:
> 
>   Streams are identified with an unsigned 31-bit integer.  Streams
>   initiated by a client MUST use odd-numbered stream identifiers; those
>   initiated by the server MUST use even-numbered stream identifiers.
> 
> This implies that pushed streams are initiated by the server.
> Section 6.8 (GOAWAY):
> 
>   Once sent, the sender will ignore frames sent on streams initiated by
>   the receiver if the stream has an identifier higher than the included
>   last stream identifier.
> 
> Also in 5.1.1:
> 
>   The identifier of a newly established stream MUST be numerically
>   greater than all streams that the initiating endpoint has opened or
>   reserved.
> 
> This seems pretty clear: once GOAWAY has been sent, any pushes that
> have not yet been reserved will be ignored.
> Additionally, if “last-stream-id” is lower than a previously reserved
> stream’s stream ID, that stream will be ignored as well.
> 
> Cory
> 
> On Thu, 23 May 2019 at 15:12, Alan Frindell <afrind@fb.com> wrote:
>> 
>> This discussion came up in the QUIC working group with respect to https://github.com/quicwg/base-drafts/issues/2632.
>> 
>> My understanding of 7540 is that a GOAWAY sent by the client will prevent the server from opening any additional push streams, without waiting to receive the push streams and then reset them.  It may also convey which pushes in flight were definitely not processed at the client.  Is this interpretation correct?
>> 
>> 
>> 
>> Thanks
>> 
>> 
>> 
>> -Alan
> 

Received on Friday, 24 May 2019 07:14:49 UTC