Re: i28 proposed replacement text

mån 2008-06-02 klockan 03:10 -0400 skrev Yves Lafon:

> Essentially for what it below, the need to verify the integrity of the 
> message.

Which in HTTP is provided by Content-MD5 (even if partly misunderstood
on 206 responses), or by Digest qop=auth-int (if implemented by
anyone..)

> It is needed when you don't cut the connection, but it is a 
> desirable property even if the connection is cut, to detect an error case 
> (like cutting the connection in the middle of a chunked stream) from a 
> normal response.

Sure, there is many things which is desireable and nice, but it doesn't
make them MUSTs..

> partial or absolute detection ? If the format allows multiple concatenated 
> entries, and integrity check is true if you reach exactly the end of one 
> entry, you have a highly probable integrity check but not an absolute one.

You don't hav an absolute one even if Content-Length matches or chunked
encoding is terminated proper. It all depends on where the failure was
and how communication was to that.. In any situation where there may be
some form or proxy inbetween (including servers running scripts) both
Content-Length and chunking is synthetic and hop-by-hop. As recipient
you can only be absolutely sure that if there is a mismatch then
something is wrong..

As sender you can be reasonably sure that if you explicitly indicate the
length by Content-Length then the recipient will get that, but chunking
does not provide this level of integrity as it's a hop-by-hop feature
which may be added/removed any number of times along the response path.

> But it is used that way in deployed servers/clients ? Or is chunked 
> encoding always the norm.

Not sure one yet can speak of a norm when talking about
transfer-encoding gzip/chunked...

Regards
Henrik

Received on Monday, 2 June 2008 08:34:26 UTC