lör 2009-07-25 klockan 23:32 -0700 skrev Roy T.Fielding: > > However, I'm wondering what a cache should do when combining > > partial responses that include Content-MD5. This doesn't seem to be > > addressed in 2616, nor in p5 or p6. > > Toss the MD5s unless it plans to recompose them. Unfortunately the process on how to combine responses says nothing about tossing this header. Additionally HTTP specification of Content-MD5 says: The Content-MD5 header field MAY be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients MAY generate the Content-MD5 header field; proxies and gateways MUST NOT generate it, as this would defeat its which forbids shared caches from recomposing Content-MD5. plus the issues in how a 206 response is to be composed which I mentioned earlier. > It is a MIME header field. (a) is the definition. Then the sections on how to combine responses and 206 both needs to be extended to emphasize this, if Content-MD5 is at all to be kept. As already demonstrated there is significant implementations out there handling Content-MD5 differently, simply from implementing different parts of the spec literally: - jigsaw implements it on the message body, recomposing Content-MD5 on each response, returning different Content-MD5 in 206 than 200. - Squid indirectly implements it on the resource by implementing the requirements of 206 composing literally ("MUST include all of the entity-headers that would have been returned with a 200 (OK)") and not caring about Content-MD5 as the specs says it is not allowed to recompose it. Regards HenrikReceived on Sunday, 26 July 2009 09:48:32 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:08 GMT