W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Streams after receiving GOAWAY

From: Glen Knowles <gknowles@ieee.org>
Date: Sun, 15 Nov 2015 10:48:32 -0800
Message-ID: <CAJCH0yDfeosp3XHzvGtC8yoWBknycs4d-z1AkuHmZ0TvbSQ-kQ@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Nov 15, 2015 at 2:52 AM, Cory Benfield <cory@lukasa.co.uk> wrote:

> GOAWAY is not intended as a mechanism for saying “I will process no more
> than n further streams”.

But that is exactly a stated purpose of GOAWAY(noerror):
"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."

> If it were, it would be totally acceptable to open all connections with
> the preamble, followed immediately by GOAWAY(last_stream_id=100). This is
> not the intended use of GOAWAY.
> Reinterpreting last_stream_id to mean "last I will send" instead of "last
of your streams I may process" would be clearly wrong, and is not what I'm
doing. I'm merely giving the listener the option to widen the existing
"inherent race condition between an endpoint starting new streams and the
remote sending a GOAWAY frame."

If your server sends a GOAWAY(no error) with the last stream id set to the
last one it's processed then my client will not open any more streams on
that connection. It will only continue to open additional streams if the
last stream you report is "in the future". I see how this could be a
problem if the server doesn't set the last stream id according to the spec,
but otherwise?
Received on Sunday, 15 November 2015 18:49:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC