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