W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

RE: RST_STREAM(OK) after an HTTP response

From: Osama Mazahir <OSAMAM@microsoft.com>
Date: Wed, 24 Sep 2014 23:28:24 +0000
To: Michaela LaVan <mlavan@google.com>, Mark Nottingham <mnot@mnot.net>
CC: Jeff Pinner <jpinner@twitter.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <6092065088ab45128940643737b2f0fd@SN2PR03MB046.namprd03.prod.outlook.com>
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/





Received on Wednesday, 24 September 2014 23:28:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC