RE: RST_STREAM(OK) after an HTTP response

On the text itself, I would make it a SHOULD NOT.  A client can already discard a response any time it wants, for any reason it wants.  Why is this one in particular deserving of an absolute prohibition?

Regardless, I don't think the issue is an incorrect implication of a state change on the wire, though if you want to make that clearer feel free.  There is an actual new state in the code that has to be introduced to support this, even if it's conceptually a "normal" RST_STREAM.

Upon receiving the RST_STREAM, we can't send any more body to the server.  But we also can't stop the layer above us from pumping body into us without aborting the request.  With any other form of RST_STREAM, we could just fail attempts to write more body, because the request was aborted by the server.  This form of RST_STREAM creates a new corner case that has to be handled in an API layer or an intermediary -- continue accepting body from the layer above, but route it to the bit bucket instead of the wire.

It's certainly possible -- it's just more code -- but our point is that permitting this does create a new state for an intermediary to handle.  (Though it's a reasonable argument that this state already existed and the text just calls attention to it in case, like us, an implementer overlooked it.)

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


On 14 Oct 2014, at 4:10 am, Matthew Cox <macox@microsoft.com> wrote:

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

I see. This text:

"""
A server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR. Clients MUST NOT discard responses as a result of receiving RST_STREAM in the corresponding "half-closed (remote)" state.
"""

can be read to say that RST_STREAM causes a state transition from "open" to "half-closed (remote)", when such a state transition isn't documented; up until now, RST_STREAM has only allowed various states to transition to "closed".

I think this could be fixed by changing the text above to:

"""
When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i.e., a frame with the END_STREAM flag). Clients MUST NOT discard responses as a result of receiving such a RST_STREAM.
"""

Does that help?


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

Received on Tuesday, 14 October 2014 16:59:47 UTC