W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: GOAWAY from a client

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 17 Mar 2016 10:47:03 +1100
Cc: "Kulkarni, Saurabh" <sakulkar@akamai.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8F45F74C-A947-4ABA-ABA6-C296A82F68AE@mnot.net>
To: Mike Bishop <Michael.Bishop@microsoft.com>
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> 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>
> 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/
Received on Wednesday, 16 March 2016 23:47:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC