Re: conflict of interest

--MimeMultipartBoundary
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Duane Wessels wrote:
>=20
> The past couple of days I have been munging squid 1.2 to support using
> SHA digests as cache keys. This is of course a result of the
> discussion some months ago about compressing URLs which then became
> 'why not just use MD5 hashes?' FWIW, I started with SHA instead of MD5
> because some people hinted it might be better and has no use
> restrictions. However, it will be easy to plug MD5 in (or any other
> scheme) should any desire to do so.

Here are some other reasons why to use a hash, and not the URL as cache
keys:
1. Is extensible. What we use to build the hash is easily extended to
include other attributes than the actual URL (for example to support
Varies:)
2. Fixed size =3D=3D much easier memory management for the cache index.

> Anyway, Kostas is working on adding hit metering into Squid and today
> we realized that hit metering will become very difficult when the
> cache key is one-way hash of the URL. When we need to purge
> an object, we're supposed to make a HEAD request for the URL to
> report the hits. But we won't have the URL any more.

Then store the URL on disk somehow (at the beginning of the disk object
for example). It is not that big problem to fetch it (and possibly other
needed variables) from the disk at purge-time. I beleive that anything
that is not needed to support ICP should as much as possible be kept on
disk.

> In fact, hit metering will require quite a bit of additional overhead
> for every object. In addition to some four integer counters, the draft
> requires that hits be reported back to the source of the object, and
> not necessarily the origin server. So we'd have to remember which
> neighbor gave us each object. ick.

See above.

> Thoughts?

I don't see any conflict that is not easily resolved.

---
Henrik Nordstr=F6m
--MimeMultipartBoundary--