Code change:
After some sleep, I've read through the section and noticed a few other minor inconsistencies. This alters the structure slightly, as well as replacing the first sentence with a more accurate one. Supercedes . .
+1, thanks
LGTM
Merged by RFC editor.
We are working on a HTTP/2 library and we are a bit confused and we would like to get it right. Is it correct that after a sender sent a frame with some to a receiver, the sender may still open new streams, even with stream identifiers higher than the sent in the frame? That is the frame and the only limit the ability of the receiver? If this is correct, and I believe it is, then I find the following sentence in the first paragraph at confusing. In my opinion it should say something of the like Thanks.
I am also intersted in getting clarity on this topic. It seems what the "spirit" of the is something like: Each endpoint maintains the goaway last stream id from its peer. When a goaway is received then no local streams can be created (i.e. streams can only transition to ), and all local streams with > from the goaway frame are closed (or as the spec says ). Remote streams can still be opened, and to ensure a graceful connection shutdown a goaway frame should be sent in response.
Not quite: Upon receipt of GOAWAY, new streams can be created, but with the following restrictions: those with stream identifiers higher than the will be ignored. Those with stream identifiers lower or equal are subject to the usual risk of loss, but they might be processed. Success is determined by what happens on the stream, of course.
NAME - Can you clarify the following from : This is what lead me to believe that streams can not be "created" after receiving a ?
Hmm. I'd forgotten that. That is in conflict with the graceful shutdown we've specified. I think that we need to take this to the list. This seems like a genuine bug.
Thanks for the quick response NAME Would you prefer to bring the issue to the list?
I'm just trying to formulate something.
hmm I see NAME As a follow up, does the in the GOAWAY have to be the identifier of a stream that actually exists or could it also just be a "random number"?
The intent was to say that the receiver of a GOAWAY can't create new streams higher than the value in GOAWAY. Let me check back in tomorrow; maybe fresh eyes will add perspective.
So the intention of the change is allow receiver of GOAWAY are still allowed to create stream lower or equal to received last-stream-id, accepting the fact that those streams are ignored by peer? As the graceful shutdown process as described in draft 17, server first sending GOAWAY with (2^31) - 1 starts to ignore any new streams created by peer and after some time (this ensures that GOAWAY is reached to the client), server sends another GOAWAY with updated last-stream-id where processing has occurred already.
NAME the intent of the change is to not change anything :) The process has been unclear, but the point is that if you receive GOAWAY with a last-stream-id greater than anything you have initiated, you can use what space remains for new streams. What that means is that you can issue new requests on that connection while you take the time to create a replacement connection. This was considered critical for . That means that 2^31-1 serves only as a warning of impending closure, though in theory it need not change any behaviour for the existing connection. I'd take steps to make a replacement connection though.
Thank you for clarification!
Here is a link to NAME doc from the mailing list which provides additional clarity to this issue URL
Latest PR is much more comfortable to me. Thanks!

Related discussion:
text: -1 and a code.  This signals to the client that a shutdown is imminent and <del> that no further requests can be initiated.  After waiting at least one round trip time, the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without losing requests. </del> <ins> that initiating further requests is prohibited.  After allowing time for any in flight stream creation - at least one round trip time - the server can send another GOAWAY frame with an updated last stream identifier.  This ensures that a connection can be cleanly shut down without causing clients to lose requests. </ins> After sending a GOAWAY frame, the sender can discard frames for <del> streams with identifiers higher than the identified last stream. However, any frames that alter connection state cannot be completely ignored.  For instance, </del> <ins> streams initiated by the receiver with identifiers higher than the identified last stream.  However, any frames that alter connection state cannot be completely ignored.  For instance, </ins> ,