W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Re: 100 Continue and Expects

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Mon, 29 Mar 2010 09:51:45 -0700
Cc: Greg Wilkins <gregw@webtide.com>, <ietf-http-wg@w3.org>
Message-Id: <A4B576D2-83C6-47F5-8D95-B755F1D9770E@yahoo-inc.com>
To: Jamie Lokier <jamie@shareable.org>

On 28/03/2010, at 7:20 AM, Jamie Lokier wrote:
> 
> I found this part of RFC2616 a little confusing:
> 
>    8.2.2 Monitoring Connections for Error Status Messages
> 
>       An HTTP/1.1 (or later) client sending a message-body SHOULD
>       monitor the network connection for an error status while it is
>       transmitting the request. If the client sees an error status,
>       it SHOULD immediately cease transmitting the body. If the body
>       is being sent using a "chunked" encoding (section 3.6), a zero
>       length chunk and empty trailer MAY be used to prematurely mark
>       the end of the message.  If the body was preceded by a
>       Content-Length header, the client MUST close the connection.
> 
> As far I know, the client does not have to close the connection, if
> it continues to transmit the rest of the body.
> 
> And if it does close, of course it shouldn't do so until it's seen the
> whole response, not just the "error status".
> 
> Moreover, I wasn't sure what _exactly_ counts as an "error status", as
> it's not a defined term, and 3xx (not an error) would seem to need the
> same behaviour.  Or even 2xx, if the request body isn't relevant.
> (Although I really like the idea of simultaneously streaming
> request and response bodies).


See <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/108>.

Cheers,

--
Mark Nottingham       mnot@yahoo-inc.com
Received on Monday, 29 March 2010 16:53:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:17 GMT