Subject: Re: proposal for issue #178

From: Yves Lafon <[email-masked]>
Date: Fri, 23 Jul 2010 06:04:05 -0400 (EDT)

On Mon, 7 Jun 2010, Henrik Nordström wrote:

> tis 2010-06-08 klockan 00:17 +1200 skrev Adrien de Croy:
>
>> I don't see any point in having an integrity check for a message
>> containing only a partial range.  Surely you want to accumulate the
>> entire entity by piecing together all the parts, and then you use the
>> MD5 to check the total.
>
> My view also, but others have read it differently in past, and the spec
> is ambigious on which reading is right with a bit blurred definition of
> 206, response entity, full response entiry and partial response entity.

Roy made some clarification in part3 today (see [874]), so basically we 
have implementations like Apache violating the spec (it sends the C-MD5 of 
the whole representation), should we warn that as of today, server 
implementations are at best inconsistent when they send C-MD5 on 206, or 
ask client that they SHOULD ignore C-MD5 on 206?

[874] http://trac.tools.ietf.org/wg/httpbis/trac/changeset/874

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

         ~~Yves

---

From: Henrik Nordström <[email-masked]>
Date: Sun, 25 Jul 2010 13:08:42 +0200

> ask client that they SHOULD ignore C-MD5 on 206?

I thought we had already agreed than 206 SHOULD NOT include C-MD5 and
clients MUST/SHOULD ignore C-MD5 in 206 responses.

The idea that C-MD5 is on the partial 206 body is imho not workable for
proxies

  a) C-MD5 is end-to-end. Proxies building 206 responses from a cached
200 response is not allowed to insert it, plus quite likely to copy it
from the 200 response if present.
  b) Not going to dynamically calculate C-MD5 on each request.

Imho the only sensible definition of C-MD5 is to digest the full 200
response payload body, not the partial body. Having it done on the
partial body requires several clarifications and warnings to be added in
206 processing.

  - Warning about inconsistent server implementations due to ambiguous
wording in RFC2616.
  - Note that C-MD5 MUST NOT be copied with combining 206 responses.
  - Note that C-MD5 MUST NOT be copied when building a 206 response
based on a cached 206 response, plus a reminder that since C-MD5 is
end-do-end it also MUST NOT be dynamically calculated by proxies.

Regards
Henrik