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

Re: RST_STREAM(OK) after an HTTP response

From: Greg Wilkins <gregw@intalio.com>
Date: Sun, 28 Sep 2014 13:28:17 +1000
Message-ID: <CAH_y2NHkTQzE8c-z-B-mkBNP_eRa=0_gZiZxxKyZkEn_sV9Vhg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Osama Mazahir <OSAMAM@microsoft.com>, Jeff Pinner <jpinner@twitter.com>, Matthew Cox <macox@microsoft.com>, Michaela LaVan <mlavan@google.com>, Mark Nottingham <mnot@mnot.net>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

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.


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.
Received on Sunday, 28 September 2014 03:28:45 UTC

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