Re: Content-MD5 and partial responses

fre 2009-07-24 klockan 04:18 -0400 skrev Yves Lafon:

> Well, Content-Length is also an entity header, however it applies to the 
> transferred bytes in case of 206.

And is specified separately for 206 responses, referring to message-body
and not entity, ruling out any doubt.

> What would be the use of C-MD5 if it applies to the whole bag of bytes 
> when you only get a part of it?

Well, Content-MD5 is often not even allowed in a 206 response
(SHOULD/MUST not include if a If-Range validator was used) which kind of
defeats the per-message idea on partial responses.

And if a validator was not used then the definition of 206 says "MUST
include all of the entity-headers that would have been returned with a
200 (OK) response to the same request." which to me says it should be
the same value as in 200 OK enabling clients to compare with other
responses to verify they all refer to the same "200 response". Yes, this
conflicts somewhat for Content-Length, but as already said the rules for
Content-Length in 206 is explicitly stated some paragraphs up in the
same section.

But it's easy to (imho wrongly) assume the per-message semantics on a
quick reading of just the definition of Content-MD5. But I can not make
the per-message semantics fit well at all when taking 206 responses into
account.

One more point on this:

      * "Only origin servers or clients MAY generate the Content-MD5
        header field; proxies and gateways MUST NOT generate it"
      * Caching proxies MAY support Range requests, turning a 200
        response into 206 partial response.
      * There is no explicit rule specifying that Content-MD5 is to be
        recalculated when making a 206 partial response from a 200
        response, other than the "copy" rule quoted above.

Similar not-per-message hints is also seen in indirectly in definition
of 304 where a careful distinction is made between message-body and
entity-body.

Regards
Henrik

Received on Friday, 24 July 2009 10:24:12 UTC