RE: RST_STREAM(OK) after an HTTP response

Just to clarify, we can reword the text from “The RST_STREAM frame (type=0x3) allows for abnormal termination of a stream” to “The RST_STREAM frame (type=0x3) allows for immediate unconditional termination of a stream” (or “abrupt”).

But that the validity of the bodies in-flight (or buffered on either send/recv) is the same as the other reset codes.  That is, all bets are off and I expect most stacks to implement immediate stream termination by dropping any buffered data on the floor.  I do not want us to get into a situation where bodies/requests/responses are expected to be valid, be it partial or ‘complete’.

To me it appears we could just use CANCEL; the text already indicates that it used deliberately by an endpoint when it is no longer interested.  If we want to add a new code then please don’t confuse it by hinting at ‘success’ and instead use something along the lines of “deliberate”, “expected”, “terminate”, “close”

From: Michaela LaVan [mailto:mlavan@google.com]
Sent: Wednesday, September 24, 2014 2:24 PM
To: Mark Nottingham
Cc: Jeff Pinner; Mike Bishop; HTTP Working Group
Subject: Re: RST_STREAM(OK) after an HTTP response

This use case has come up for us recently as well. I like Jeff's suggestion both the client and server should be explicitly free to send a RST_STREAM at any time without it necessarily indicating an error.

On Wed, Sep 24, 2014 at 1:29 PM, Mark Nottingham <mnot@mnot.net<mailto:mnot@mnot.net>> wrote:
I’ve heard at least one other person bring up this scenario recently (forget who), FWIW. We should clarify, I think.


On 24 Sep 2014, at 5:11 pm, Jeff Pinner <jpinner@twitter.com<mailto:jpinner@twitter.com>> wrote:

>> While I understand the scenario, it seems more appropriate for the client to send the RST_STREAM(OK) if it decides to abort sending the rest of the body.
>
> I think that should be valid as well. Basically I think either should
> be able to tear down the stream via RST_STREAM(OK) without the other
> considering it an error, and that the text should be clarified to make
> it explicit.
>
--
Mark Nottingham   http://www.mnot.net/