RE: GOAWAY from a client

That wasn't the intent; the sender of an GOAWAY frame ought also to be prohibited from opening new streams. However, glancing through RFC 7540, I can't actually find that prohibition. I suspect that’s the erratum, unless that's explicitly stated in another section and I'm just not finding it right now. While GOAWAY frames are bidirectional, most of the focus was obviously on the server-to-client direction.

From: Kulkarni, Saurabh [mailto:sakulkar@akamai.com]
Sent: Wednesday, March 16, 2016 4:51 PM
To: Mark Nottingham <mnot@mnot.net>; Mike Bishop <Michael.Bishop@microsoft.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: GOAWAY from a client

So this means GOWAY from a client does not affect client affected streams at all right meaning it can happily keep initiating new streams after sending a GOAWAY (which is kinda odd since its the opposite of “go away” :) ).

- Saurabh

From: Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>>
Date: Wednesday, March 16, 2016 at 4:47 PM
To: Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>>
Cc: Saurabh Kulkarni <sakulkar@akamai.com<mailto:sakulkar@akamai.com>>, HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: GOAWAY from a client

Go ahead and submit an errata; worst case, we can hold it for a future update.


On 17 Mar 2016, at 10:35 AM, Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote:
“To deal with this case, the GOAWAY contains the stream identifier of the last peer-initiated stream that was or might be processed on the sending endpoint in this connection.  For instance, if the server sends a GOAWAY frame, the identified stream is the highest-numbered stream initiated by the client.”

And conversely, if the client sends a GOAWAY frame, the identified stream is the highest-numbered stream initiated by the server. Since the server has initiated no streams, the highest is zero. At this point, the server is prohibited from initiating new streams (pushing) and the client is indicating that it will initiate no further requests on the connection.

The text you're quoting, further down, could probably be clarified to indicate that it's referring only to streams initiated by the recipient. Does that qualify as an errata?

From: Kulkarni, Saurabh [mailto:sakulkar@akamai.com]
Sent: Wednesday, March 16, 2016 4:18 PM
To: HTTP Working Group <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: GOAWAY from a client

We are seeing a GOAWAY from the client with stream_id=0 and NO_ERROR. Other than disabling push for the future does this serve any other purpose? I believe the text says this:

"If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those streams are not or will not be processed. The receiver of the GOAWAY frame can treat the streams as though they had never been created at all, thereby allowing those streams to be retried later on a new connection.”

So the scenario is this:
Client -> HEADERS (stream id = 1)
Client -> HEADERS (stream id = 3)
Client -> GOAWAY (last stream id = 0) (last peer initiated stream id)

According to the draft text above, server is supposed to ignore everything above stream id = 0. Also, if the server does the sensible thing here of allowing responses to go thru for stream 1 and 3, should it disallow additional streams to be initiated by the client? I am assuming here that the server cannot push any streams as  it has received GOAWAY from the client.

- Saurabh

--
Mark Nottingham   https://www.mnot.net/