RE: RST_STREAM(OK) after an HTTP response

So you are saying the request-side has failed, but the response-side hasn't?

This is what I would push back on.  Any buffered data at the time of receiving RST_STREAM should be allowed to be dropped on the floor.  There should be no guarantee that it will flow up the stack if the other side sends a RST_STREAM.

Even if I did allow the buffered data to stay, I'd have to fail the send side up the stack, and then the whole stack would have to know that receives are still valid even during a send failure.

To me the problem Jeff presented is an application layer problem.  In his example the termination of the request is based off of the receipt of a response, but since the application doesn't adhere to that, he wants to force it by resetting the stream.  What I think he should do is what most 1.1 stacks are doing now which is have a heuristic on how long you are willing to let the client keep sending data after you already told it that you weren't interested, and once it passes some threshold you reset it dropping everything on the floor.

Matthew

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Thursday, September 25, 2014 11:53 PM
To: Matthew Cox
Cc: Greg Wilkins; Osama Mazahir; Michaela LaVan; Mark Nottingham; Jeff Pinner; Mike Bishop; HTTP Working Group
Subject: Re: RST_STREAM(OK) after an HTTP response

On 25 September 2014 21:52, Matthew Cox <macox@microsoft.com> wrote:
> Is there a pull request for this that we can review?

Not yet, no.

The text would include a small tweak to RST_STREAM (s/abnormal/abrupt/ as Jeff suggests, or something similar).

Then the HTTP mapping would note that a response should not be considered failed if a RST_STREAM is received by a client in the "half-closed (remote)" state, because the response would have been completely received.

Received on Friday, 26 September 2014 17:09:35 UTC