Re: #318, was: Closing the connection

On Oct 25, 2011, at 1:38 AM, Julian Reschke wrote:

> On 2011-10-25 09:46, Julian Reschke wrote:
>> On 2011-10-25 02:11, Mark Nottingham wrote:
>>> 
>>> On 25/10/2011, at 12:34 AM, Julian Reschke wrote:
>>> 
>>>> Hi,
>>>> 
>>>> in<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-16.html#rfc.section.7.1.4.p.5>
>>>> we say:
>>>> 
>>>> "Servers SHOULD NOT close a connection in the middle of transmitting
>>>> a response, unless a network or client failure is suspected."
>>>> 
>>>> Really? As far as I recall, it's the only way for a server to signal
>>>> the presence of a problem once it has started to send the response body.
>>> 
>>> 
>>> 
>>> Perhaps change to:
>>> 
>>> 
>>> "... unless a network or client failure is suspected, or a problem in
>>> generating the response necessitates abandoning it. See [ref to p6]
>>> for details of how caches will treat incomplete responses."
>> 
>> +1
>> 
>> Now tracked as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/318>.
> 
> Proposed patch: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/318/318.diff>.
> 
> This changes the paragraph to:
> 
>   Servers SHOULD always respond to at least one request per connection,
>   if at all possible.  Servers SHOULD NOT close a connection in the
>   middle of transmitting a response, unless a network or client failure
>   is suspected, or a problem in generating the response necessitates
>   abandoning it.  See Section 2.1 of [Part6] for details of how caches
>   will treat incomplete responses.
> 
> 
> and adds to the Changes section:
> 
>   Remove hard limit of two connections per server.  Remove requirement
>   to retry a sequence of requests as long it was idempotent.  Allow
>   servers to close the connection when an internal error happens while
>   the response payload is generated.  (Section 6.1.4)
> 
> Best regards, Julian

I'd rather just delete the paragraph.  It is a useless requirement.
Servers drop connections only when there is no other choice, and
the reasons usually have nothing to do with HTTP.

....Roy

Received on Wednesday, 26 October 2011 00:39:32 UTC