Subject: Re: i28 proposed replacement text

From: Yves Lafon <[email-masked]>
Date: Wed, 2 Jul 2008 13:05:36 -0400 (EDT)

To sum up, the current text should not be changed, as it is valid to cut 
the connection to signal the end of the tranfer, even if Transfer-Encoding 
is used _without_ using chunked encoding.

However, if it was raised as an issue, it deserves clarification, and most 
probably a warning.

So, in 4.4, item 2:

<<<
2.  If a Transfer-Encoding header field (Section 8.7) is present,
        then the transfer-length is defined by use of the "chunked"
        transfer-coding (Section 3.4), unless the message is terminated
        by closing the connection.
replaced by
<<<
2.  If a Transfer-Encoding header field (Section 8.7) is present, and
        the "chunked" transfed-coding (Section 3.4) is used, the
        transfer-length is defined by the use of this transfer-coding.
        If the "chunked" transfer-coding is not present, the
        transfer-length is defined by [the emitter] closing the connection.

        Warning: If the transfer-length is defined by closing the
        connection, the transfer-coding used might not have characteristics
        to ensure that the  sender and the recipient sent/received the same
        message.

As it doesn't make much sense for a client to close the connection after 
sending an entity using TE without chunk, we can just replace [the 
emitter] (in [] just to show it needs a better wording) by 'the server'.
Cheers,

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 02 Jul 2008 22:29:36 +0200

> However, if it was raised as an issue, it deserves clarification, and most 

Agreed.

>         to ensure that the  sender and the recipient sent/received the same

Looks fine. But I think the warning part is overkill and only confuses
matters, but won't object it if others thinks it's needed.

I've already said many times that HTTP does not strictly provide this
guarantee even if chunked is used as the chunking may have been added
along the path.

If energy is to be spent on explaining the "message integrity"
properties of HTTP then some better wording on what constitutes an
incomplete message, and how recipients should act when seeing one,
especially proxies.. But most seems to get this right by intuition, but
I think it's important to add that a proxy detecting a partial message
by seeing a connetion close either before Content-Length octets or
before a chunked end-chunk when the message is using chunked SHOULD
close the proxied connection without signalling the end-chunk to the
recipient, and that caches MUST consider the message partial. This to
avoid the next-hop mistakenly beleiving the partial message is proper.

> emitter] (in [] just to show it needs a better wording) by 'the server'.

Yes.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Jul 2008 23:13:14 +0200

>>         transfer-length is defined by [the emitter] closing the connection.

Can we rephrase that without using the term "emitter" (is the the same 
as "sender"?), and without brackets?

> matters, but won't object it if others thinks it's needed.

Do we have consensus for at least making the first part of the change 
(with "[the emitter]" being replaced as suggested below)?

> avoid the next-hop mistakenly beleiving the partial message is proper.

Sounds good. Can you propose text for Part 6, covering this?

> ...

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Wed, 02 Jul 2008 23:30:36 +0200

> as "sender"?), and without brackets?

The complete proposal was "the server" (without brackets or quotes..)

> (with "[the emitter]" being replaced as suggested below)?

It's a +1 from me.

> Sounds good. Can you propose text for Part 6, covering this?

I'll give it a shot. If you haven't heard from me tomorrow evening ping
me again.

Regards
Henrik

---

From: Julian Reschke <[email-masked]>
Date: Sat, 05 Jul 2008 12:28:39 +0200

...

Going back to <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/28>, 
MNot also suggested a change to 3.4:

> p1 3.4, "Transfer Codings":
> 
> Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message indicates it is terminated by closing the connection. 

Which sounds right to me.

So my proposal would be:

Section 3.4., paragraph 5:
OLD:

    Whenever a transfer-coding is applied to a message-body, the set of
    transfer-codings MUST include "chunked", unless the message is
    terminated by closing the connection.  When the "chunked" transfer-
    coding is used, it MUST be the last transfer-coding applied to the
    message-body.  The "chunked" transfer-coding MUST NOT be applied more
    than once to a message-body.  These rules allow the recipient to
    determine the transfer-length of the message (Section 4.4).

NEW:

    Whenever a transfer-coding is applied to a message-body, the set of
    transfer-codings MUST include "chunked", unless the message indicates
    it is terminated by closing the connection.  When the "chunked"
    transfer-coding is used, it MUST be the last transfer-coding applied
    to the message-body.  The "chunked" transfer-coding MUST NOT be
    applied more than once to a message-body.  These rules allow the
    recipient to determine the transfer-length of the message
    (Section 4.4).

Section 4.4:
OLD:

NEW:

    2.  If a Transfer-Encoding header field (Section 8.7) and the
        "chunked" transfer-coding (Section 3.4) is used, the transfer-
        length is defined by the use of that this transfer-coding.  If
        the "chunked" transfer-coding is not present, the transfer-length
        is defined by the sender closing the connection.

See also 
<http://www.tools.ietf.org/wg/httpbis/trac/attachment/ticket/28/i28.diff>.

BR, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Sat, 05 Jul 2008 14:38:52 +0200

>         is defined by the sender closing the connection.

Hmm.. "is present" fell off somewhere.

        If a Transfer-Encoding header field (Section 8.7) is present and
        the "chunked" transfer-coding [...]
        
And to rule out any chance of people getting confused over "closing the
connection" one should perhaps overstate the Transfer-Encoding header..
last sentence again

        [...]. If a Transfer-Encoding header field is present and the
        "chunked" transfer-coding is not present, the transfer-length is
        defined by the sender closing the connection.

Regards
Henrik

---

From: "Robert Brewer" <[email-masked]>
Date: Sat, 5 Jul 2008 09:13:31 -0700

>         is defined by the sender closing the connection.

"...that this transfer-coding" needs a grammar tweak.

Robert Brewer
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Sat, 05 Jul 2008 19:05:21 +0200

> Hmm.. "is present" fell off somewhere.

Sorry.

>         defined by the sender closing the connection.

Sounds good.

> "...that this transfer-coding" needs a grammar tweak.

Indeed. I was flip-flopping between "this" and "that" and ended up with 
both. Sorry.

New proposal:

    2.  If a Transfer-Encoding header field (Section 8.7) is present and
        the "chunked" transfer-coding (Section 3.4) is used, the
        transfer-length is defined by the use of this transfer-coding.
        If a Transfer-Encoding header field is present and the "chunked"
        transfer-coding is not present, the transfer-length is defined by
        the sender closing the connection.

Also in 
<http://www.tools.ietf.org/wg/httpbis/trac/attachment/ticket/28/i28.2.diff>.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Jul 2008 13:23:16 +0200

> <http://www.tools.ietf.org/wg/httpbis/trac/attachment/ticket/28/i28.2.diff>. 

Proposed patch applied and issue closed with 
<http://www3.tools.ietf.org/wg/httpbis/trac/changeset/276>.

BR, Julian