- 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>
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? 2c, Adrian
Received on Wednesday, 1 July 2009 02:32:58 UTC