Re: RST_STREAM(OK) after an HTTP response

It seems like we've circled back to the original suggestion.

Martin, can you please prepare a pull request here?

Thanks,


On 28 Sep 2014, at 1:28 pm, Greg Wilkins <gregw@intalio.com> wrote:

> 
> On 27 September 2014 20:24, Martin Thomson <martin.thomson@gmail.com> wrote:
> There is an alternative: recommend that clients reset their own
> request streams once the response is received.
> 
> This would break existing applications.   It is perfectly legal HTTP to send a response and then consume the request content.   Clients should not reset the stream after the response is read as the server may still wish to consume the body being sent.
> 
> Sure, in many/most use-cases it is entirely premature for a server to send a response before consuming the body, but there are use-cases where it does make sense... or at least where it is currently done and expected to keep working.
> 
> The only party that knows if the request body is required or not is the server.   It's perfectly able to send a reset now, and I think the only real issue is that the spec says that resets are "abnormal termination".   Renaming that to an "immediate termination" and using the existing NO_ERROR code would cover this case.
> 
> cheers
> 
> 
> -- 
> 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.

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 7 October 2014 06:15:34 UTC