Re: GOAWAY clarification

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 07:13:10 UTC