Page 3 - i28 proposed replacement text

>>But one question stays: should a client/proxy retry if it detects a
>>truncated message? - As I read RFC2616: yes (especially if the method is
>>safe).
>
>Perfectly fine for user agents, but not so sure about proxies. But the
>partial response MAY be cached and completed using range requests.

, so if the proxy gets a reply using connection closure to signal the
end of the reply, should the proxy always treat this as an incomplete
transaction?

course not (as the proxy can not detect truncated messages this way).


Robert

tor, 2008-06-05 at 09:55 -0400, Yves Lafon wrote:

The proxy may add a Warning header to indicate this, it would be a better
match than closing the connection in the middle of a chunk.

Most times it's too late to add a header as the header portion has
already been sent to the requesting client, and you can't send a trailer
header without both the following

- Indication of positive response without error
- The headers you place in the trailer needs to be advertised in the
initial header portion.

question is if a Transfer encoding of gzip is used + connection
closure form the server to the proxy, and the client sent a TE: gzip to
the proxy, should the proxy gunzip the content, then gzip it back (as
TE/TEncoding is hop-by-hop) ? (and it that case an error may be noticed) ?

Doesn't really matter for the initial request, but it should at least
verify the Transfer-Encoding if storing the object in cache and discard
the object if the Transfer-Encoding isn't decodeable.


Regards
Henrik

tor, 2008-06-05 at 05:01 -0400, Yves Lafon wrote:

, so if the proxy gets a reply using connection closure to signal the
end of the reply, should the proxy always treat this as an incomplete
transaction ?

No, only if the length disagrees with Content-Length or if chunked
encoding was not properly terminated.

A message without content-lenght or chunked encoding is validly
terminated by closing the connection.

Servers who require the client to ALWAYS be able to detect truncated
messages SHULD use Content-Length. It's the only transmission method
where the message format guarantees possible end-to-end detection of
truncation (ignoring setups with non-transparent proxies perforing
content encoding in the mix). Yes, this rules out using
Transfer-Encoding. Additionally it's wise to use Content-MD5 for real
integrity checks.

Servers only needing this at best effort level is free to use
transfer-encoding, any of the defined ones or combinations, but be aware
that the transfer encoding MAY be removed before the response reaches
the recipient. They SHULD NT delimit messages by closing the
connection.

Regards
Henrik

Thu, 5 Jun 2008, Adrien de Croy wrote:

connection closure only signals end of message if the message had no
Content-Length header, and was not chunked.
>
, if there is a Content-Length header, (and not chunked) then the
message is complete when the number of bytes indicated have been received.
The connection can then be kept open (classic Connection: keep-alive without
chunking).

[]

Therefore it makes sense for the proxy to simply abortively close the
connection to the client and let the client deal with it, that then conveys
the (useful) information to the client that the transfer was aborted.


The issue seems to be message integrity (which can be somehow assessed by
the receiving end) and entity integrity (only applications can try to do
that).

In Henrik's example, the proxy wasn't able to assess that the received
message was complete or not (at the HTTP level), and it won't try to
inspect it. the other side, the client talking to the proxy will
receive a complete message, however the entity carried maynot be complete.

The proxy may add a Warning header to indicate this, it would be a better
match than closing the connection in the middle of a chunk.

question is if a Transfer encoding of gzip is used + connection
closure form the server to the proxy, and the client sent a TE: gzip to
the proxy, should the proxy gunzip the content, then gzip it back (as
TE/TEncoding is hop-by-hop) ? (and it that case an error may be noticed) ?

--
Baroula que barouleras, au toujou t'entourneras.

~~Yves

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 toujou t'entourneras.

~~Yves

ons, 2008-07-02 at 23:13 +0200, Julian Reschke wrote:

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

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

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

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

It's a +1 from me.

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

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

PGP SIGNATURE
Version: GnuPG v1.4.7 (GNU/Linux)




mwlW4o6Pcd8=
=K7+r
PGP SIGNATURE

Henrik Nordstrom wrote:
ons, 2008-07-02 at 13:05 -0400, Yves Lafon wrote:
>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.

Agreed.

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

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

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

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.

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

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

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



BR, Julian

ons, 2008-07-02 at 13:05 -0400, Yves Lafon wrote:
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.

Agreed.

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.


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

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,

Yes.

Regards
Henrik

PGP SIGNATURE
Version: GnuPG v1.4.7 (GNU/Linux)




9rdnvsRfwQ==
=Kins
PGP SIGNATURE

¶r, 2008-07-05 at 12:28 +0200, Julian Reschke wrote:
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.

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

PGP SIGNATURE
Version: GnuPG v1.4.7 (GNU/Linux)




HpjRue1E12g=
=wr+d
PGP SIGNATURE