Subject: Closing the connection

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Oct 2011 15:34:13 +0200

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.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 25 Oct 2011 11:11:49 +1100

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."

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Oct 2011 09:46:55 +0200

On 2011-10-25 02:11, Mark Nottingham wrote:
>> in<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-16.html#rfc.section.7.1.4.p.5>  we say:
>>

+1

Now tracked as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/318>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Oct 2011 10:38:03 +0200

On 2011-10-25 09:46, Julian Reschke wrote:
>>> "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
>

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Oct 2011 10:47:20 +1100

Sounds good.

On 25/10/2011, at 7:38 PM, Julian Reschke wrote:

> Proposed patch: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/318/318.diff>.
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 25 Oct 2011 17:39:07 -0700

>   the response payload is generated.  (Section 6.1.4)

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 26 Oct 2011 11:40:48 +1100

> the reasons usually have nothing to do with HTTP.

That works too.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 26 Oct 2011 09:41:21 +0200

>> the reasons usually have nothing to do with HTTP.

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1455>

The paragraph is gone; and I have added a sentence to the Changes 
section noting that.

Best regards, Julian