- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Wed, 8 Oct 2014 17:52:48 +0000
- To: Martin Thomson <martin.thomson@gmail.com>, Matthew Cox <macox@microsoft.com>
- CC: Mark Nottingham <mnot@mnot.net>, Greg Wilkins <gregw@intalio.com>, "Osama Mazahir" <OSAMAM@microsoft.com>, Jeff Pinner <jpinner@twitter.com>, "Michaela LaVan" <mlavan@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
I wouldn't expect MAX_CONCURRENT_STREAMS to be affected -- the client would believe there was an extra active stream, and not use as many as the server allowed. The server would start emitting RST_STREAM(STREAM_CLOSED) frames every RTT or so, though, and might eventually kick the client out for continuing to send on a closed stream. -----Original Message----- From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Wednesday, October 8, 2014 10:44 AM To: Matthew Cox Cc: Mark Nottingham; Greg Wilkins; Osama Mazahir; Jeff Pinner; Michaela LaVan; Mike Bishop; HTTP Working Group Subject: Re: RST_STREAM(OK) after an HTTP response On 8 October 2014 09:25, Matthew Cox <macox@microsoft.com> wrote: > Does RST_STREAM with NO_ERROR transition state to "closed", or is this a new state? It's RST_STREAM, so it transitions to "closed". It's not a special case. The only thing special here is that once a response is complete, RST_STREAM cannot cause the client to discard the response. That means that you shouldn't allow a RST_STREAM to abort an already completed response. That said, there are plenty of other reasons that a response might have to be discarded, it's just that racing the RST_STREAM with the response completion is probably a bad idea. > Obviously all data up to the other side's window must be allowed (because it may already be in flight), but will the receiver keep opening window after sending this new kind of RST_STREAM? Anything that the client has sent, or has commited to a send buffer, will go out. There's no obligation on any peer that has sent RST_STREAM to continue to open the flow control window. In fact, I think that it's illegal. > The way it reads right now, it almost sounds like RST_STREAM (NO_ERROR) is advisory and doesn't transition the stream to the terminal state. > > If this is the case then there is a simple workaround for us; we just ignore RST_STREAM (NO_ERROR). That would produce interesting results. Probably nothing immediately obvious, but you could end up exceeding MAX_CONCURRENT_STREAMS.
Received on Wednesday, 8 October 2014 17:53:17 UTC