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

Re: Content-MD5 and partial responses

From: Adrian Chadd <adrian@creative.net.au>
Date: Wed, 1 Jul 2009 10:32:20 +0800
To: Yves Lafon <ylafon@w3.org>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, Larry Masinter <LMM@acm.org>
Message-ID: <20090701023220.GJ23565@skywalker.creative.net.au>
On Tue, Jun 30, 2009, Yves Lafon wrote:

> >a) C-MD5 applies to the bytes in the entity-body (as above), and therefore 
> >we need to specify what a cache does with it when it combines partial 
> >responses (throw it away?).
> >
> >b) C-MD5 applies to the *full* response body, avoiding the combination 
> >issues, and allowing clients to do a MIC of the full response (assuming 
> >they have it), but removing the ability to do a MIC on a partial response 
> >on its own.
> >
> >Anybody aware of C-MD5 being used with partial responses in the wild (I'm 
> >looking at you, Adobe)?
> A while back, I implemented option a) as it seemed to be the most logical 
> interpretation of the spec.

Have you tested how well this particular assumption scales for intermediary
proxies and origin servers working on large objects?

> Caches should "throw away" the md5 (after verification of the partial body 
> received, and it is up to the cache to recompute the md5 sum of the bytes 
> served.

This requires the origin and cache to slurp in the required reply data off
disk before calculating the C-MD5 header. For small objects this is fine
but for large objects it could mean a -lot- of doubled up disk IO.

C-MD5 would make sense in this situation (as a message integrity check)
if it were a trailer header rather than an initial reply header.

How does this compare to the use of E-Tags, for example, with full and
range responses? Why would you do something different?


Received on Wednesday, 1 July 2009 02:32:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:50 UTC