Code change:
6.8. <del> The GOAWAY frame (type=0x7) informs the remote peer to stop creating streams on this connection.  GOAWAY can be sent by either the client or the server.  Once sent, the sender will ignore frames sent on any new streams with identifiers higher than the included last stream identifier.  Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams, while still finishing processing of previously established streams.  This enables administrative actions, like server maintenance. </del> <ins> The GOAWAY frame (type=0x7) is used to initiate shutdown of a connection or to signal serious error conditions.  GOAWAY allows an endpoint to gracefully stop accepting new streams, while still finishing processing of previously established streams.  This enables administrative actions, like server maintenance. </ins> There is an inherent race condition between an endpoint starting new streams and the remote sending a GOAWAY frame.  To deal with this

Related discussion:
text: 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"?