Re: Content-MD5 and partial responses

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
Henrik

Received on Sunday, 26 July 2009 09:48:32 UTC