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> wrote:

> On 24 September 2014 16:28, Osama Mazahir <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>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.