W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: proposal for issue #178

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Sun, 25 Jul 2010 13:08:42 +0200
To: Yves Lafon <ylafon@w3.org>
Cc: Adrien de Croy <adrien@qbik.com>, ietf-http-wg@w3.org
Message-ID: <1280056122.4833.20.camel@henriknordstrom.net>
fre 2010-07-23 klockan 06:04 -0400 skrev Yves Lafon:

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

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
Received on Sunday, 25 July 2010 11:09:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:23 GMT