Dancer writes:
| Alessio Bragadini wrote:
| >
| > HTTP/1.1 does, by Content-MD5 header: it's a MD5 digest of the
| > object. That leads to wonder when (and if) Squid should go to be fully
| > 1.1-aware.
|
| I think it should. HTTP/1.1 does lots of things for caches and cache
| efficiency. It seems only fair to support it :) The MD5 digest would
| certainly solve a lot of my redirection if it worked towards helping
| rationalize the merging of cached objects with distinct URLs.
Some Content-MD5 support has been in Apache and NCSA httpd's for a
while, but I didn't do a great job on it & hence it's turned off by
default. The main problem is that it recalculates the MD5 checksum
each time a (static) object is requested, which makes the HTTP server
quite a bit slower.
There ought to be an in-memory and/or on-disk cache of the checksums.
I did wonder whether it might not be better to calculate them using a
separate process, but am not too keen on this because I want
Content-MD5 to be something fundamental, rather than an add-on.
Ideally the HTTP server would be generating a Harvest Gatherer style
index too... :-)
Quick straw poll: if you were going to beef up this existing
Content-MD5 code with a bit of caching in the HTTP server, would you go
for memory (top NNN objects), disk (e.g. [N]DBM database), or both ?
Would it be reasonable to stat the file each time it's requested via
HTTP, create a checksum if not present already, and refresh the
existing checksum if the file's timestamp has changed ?
Cheerio,
Martin
Received on Wed Dec 04 1996 - 12:21:45 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:33:49 MST