- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 8 Oct 2014 10:44:10 -0700
- To: 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>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
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:44:38 UTC