Re: Streams after receiving GOAWAY
From: Glen Knowles <gknowles@ieee.org>
Date: Sun, 15 Nov 2015 10:48:32 -0800
To: HTTP Working Group <ietf-http-wg@w3.org>
Date: Sun, 15 Nov 2015 10:48:32 -0800
To: 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 10:24:44 UTC
Message-ID: <CAJCH0yBs5LxvYmgvbLHX7NgSptfBUF4TB7tw_OeuyFpTiiLbUg@mail.gmail.com>
Contemporary messages sorted by: date, thread, subject, author
This archive was generated by hypermail 2.3.1: Sunday, 15 November 2015 10:24:47 UTC