RE: RST_STREAM(OK) after an HTTP response

> The proposal isn't for a new kind of RST_STREAM; it only illustrates how the frame interacts with HTTP semantics in a particular situation.

This is a new kind of RST_STREAM.  Previously all implementations could put their streams in an aborted state when receiving RST_STREAM and fail all I/O.  Now the reset code has to be checked and special logic must be done when getting NO_ERROR which puts the stream in a new state which I would call draining send data.  Once sends are complete (END_STREAM would have been sent if sending was allowed) then the state can be transitioned to a regular closed state (non-abortive).

Matthew

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Saturday, October 11, 2014 11:52 PM
To: Matthew Cox
Cc: Martin Thomson; Osama Mazahir; Mike Bishop; HTTP Working Group
Subject: Re: RST_STREAM(OK) after an HTTP response

Matthew,

On 9 Oct 2014, at 3:25 am, Matthew Cox <macox@microsoft.com> wrote:

> This is still a -1 from our side.
> 
> Does RST_STREAM with NO_ERROR transition state to "closed", or is this a new state?

I really don't see how you can read it as creating a new state -- what in the proposal leads you to that impression?


> 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?

The proposal isn't for a new kind of RST_STREAM; it only illustrates how the frame interacts with HTTP semantics in a particular situation.


> 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.  

How do you get that? It currently reads:

> Clients MUST NOT discard responses as a result of receiving RST_STREAM in the corresponding "half-closed (remote)" state.


> If this is the case then there is a simple workaround for us; we just ignore RST_STREAM (NO_ERROR).

I think you've misunderstood the proposal. The recipient of *any* RST_STREAM is required to process it as per <http://http2.github.io/http2-spec/#RST_STREAM>, with the specified effects upon stream state. If you ignore the RST_STREAM, your implementation will not be conformant. 

This specifically includes:

> After receiving a RST_STREAM on a stream, the receiver MUST NOT send additional frames for that stream, with the exception of PRIORITY.

Cheers,


> 
> Matthew
> 
> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net] 
> Sent: Tuesday, October 07, 2014 3:51 PM
> To: Martin Thomson
> Cc: Greg Wilkins; Osama Mazahir; Jeff Pinner; Matthew Cox; Michaela LaVan; Mike Bishop; HTTP Working Group
> Subject: Re: RST_STREAM(OK) after an HTTP response
> 
> Thanks. I think we're close to consensus on this -- anyone have further questions / pushback?
> 
> Cheers,
> 
> 
> On 8 Oct 2014, at 9:02 am, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
>> On 6 October 2014 23:15, Mark Nottingham <mnot@mnot.net> wrote:
>>> Martin, can you please prepare a pull request here?
>> 
>> https://github.com/http2/http2-spec/pull/624
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Monday, 13 October 2014 17:10:39 UTC