- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Oct 2014 17:15:00 +1100
- To: Greg Wilkins <gregw@intalio.com>, 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>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
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