RE: RST_STREAM(OK) after an HTTP response

We’ve been discussing this internally, and we are unsure about what this actually means for the protocol.

Is there a pull request for this that we can review?

Thanks,

Matthew

From: Greg Wilkins [mailto:gregw@intalio.com]
Sent: Thursday, September 25, 2014 1:26 PM
To: Martin Thomson
Cc: Osama Mazahir; Michaela LaVan; Mark Nottingham; Jeff Pinner; Mike Bishop; HTTP Working Group
Subject: Re: RST_STREAM(OK) after an HTTP response

I'm good with the clarification.
But just a reminder that it should still be OK for a server to send an early response and still consume the request body.
cheers

On 25 September 2014 17:17, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
On 24 September 2014 16:28, Osama Mazahir <OSAMAM@microsoft.com<mailto:OSAMAM@microsoft.com>> wrote:
> 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’.

There is another potential way this could work.  There are two ways a
client might consider a request "done", either the presence of
END_STREAM on the response side of the stream OR the transition of the
stream into the "closed" state.  This latter option that really causes
issues.

Then there is the concern above, where the RST_STREAM acts as an
interrupt and a trigger for the request being destroyed.  This seems
far more likely to me, partially because it's basically an essential
part of how you implement RST_STREAM handling anyway.

If people are generally OK with a clarification, either because their
implementation handles this gracefully, or because they are willing to
make the necessary changes, then I think we should make the change.
It seems like a valuable feature.  But I don't want to be saying
things about this if it is going to cause implementations considerable
pain.

Would the clarification Jeff requests break your implementation?  (And
are you unable or unwilling to make a change?)



--
Greg Wilkins <gregw@intalio.com<mailto:gregw@intalio.com>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.