GOAWAY clarification

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.

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.

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.

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".

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.

Received on Saturday, 21 March 2015 05:53:36 UTC