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

Re: clarification of 7.2.2. Monitoring Connections for Error Status Messages

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 16 Apr 2010 11:20:47 +1000
Cc: ietf-http-wg@w3.org
Message-Id: <D92916FC-777D-46B4-B83B-41ED834AD8D4@mnot.net>
To: Wenbo Zhu <wenboz@google.com>
It doesn't disallow it.


On 16/04/2010, at 11:18 AM, Wenbo Zhu wrote:

> On Thu, Apr 15, 2010 at 6:16 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> The server isn't required to wait for the entire request before sending a status. Is that what you're looking for?
> more precisely, the message body as well ... and yes, I want to know
> if the spec explicitly disallows such behavior.
> 
>> 
>> 
>> On 16/04/2010, at 9:44 AM, Wenbo Zhu wrote:
>> 
>>> As a client is sending a message-body over the network connection,
>>> will any non-error response status (as well as the message body) be
>>> allowed, at all?
>>> 
>>> Section 7.2.2 & 5.0 seems to suggest otherwise, but not strongly enough IMO.
>>> 
>>> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09
>>> 
>>> "
>>> 5.  Response
>>> 
>>>   After receiving and interpreting a request message, a server responds
>>>   with an HTTP response message.
>>> 
>>> 7.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 6.2), 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.
>>> "
>>> 
>>> - Wenbo
>>> 
>> 
>> 
>> --
>> Mark Nottingham     http://www.mnot.net/
>> 
>> 


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 16 April 2010 01:21:22 GMT

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