Re: NEW ISSUE: Monitoring Connections text

what sort of network error is being envisaged here?

One that still permits data to be sent?  I'm not aware of any sorts of 
network errors that you can actually monitor for, or receive 
notification of other than a reset or close.  Other types of errors 
typically don't require any action at all - i.e. don't pertain to that 
connection, nor affect the ability to send data on the connection.

In my experience, the only option upon discovery of a network error is 
to close the connection, no chance to send a final chunk or anything.

Otherwise it looks like the spec is suggesting we keep talking down the 
phone line when the other person has hung up... a bit pointless really.

Also, IMO it's a really BAD idea to send a final chunk if you didn't 
send the whole thing, because then if the other end receives it, it 
can't tell that the transfer was aborted.

So, IMO the only sensible option is to terminate the connection.

just my 2c


Henrik Nordstrom wrote:
> On ons, 2007-11-21 at 16:50 +0100, Bjoern Hoehrmann wrote:
>   
>> Hi,
>>
>>   Section "8.2.2 Monitoring Connections for Error Status Messages" has:
>>
>>    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.
>>
>> This is somewhat confusing, it uses RFC 2119 keywords even though it
>> really just makes statements of fact (if you cease transmitting, you
>> cannot meaningfully maintain the connection) and it's unclear whether
>> clients may still send a non-empty trailer. Better would be e.g.
>>     
>
> Personally I find the text quite clear. The way I read it it's a chain
> of conditions.
>
> 1. client SHOULD monitor
> 2. If monitoring and seeing an error it SHOULD ..(if not monitoring it
> won't see the error, so the rest do not apply then) 
> 3. If chunked then it MAY terminate the body using chunked encoding
> 4. Else (Content-Length) it MUST close the connection.
>
> The only change I'd like to do there is in the last part, replacing
>
>   of the message. If the body was.. [to the end] with simply
>
>   else the client MUST close the connection.
>
> to close the blank spot where the client is using chunked encoding but
> do not want to use chunked encoding to prematurely mark the end of the
> client message.
>
> Extending the text to bind the first two SHOULD together in a chain
> isn't needed imho. Should be rather obvious that you can't see things if
> you don't monitor. 
>
>   
>>    A 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 cease transmitting the body.
>>    Unless the body is being sent using the "chunked" encoding the client
>>    MUST close the connection.
>>     
>
> This is imho less clear than the original. Especially regarding how to
> prematurely end a chunked message which in my experience isn't very
> obvious to most people that you can.. (anyone remember the NTLM auth
> discussion here some months ago?)
>
> Regards
> Henrik
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Wednesday, 21 November 2007 21:15:50 UTC