Re: store MD5 keys

On Sun, 2002-09-08 at 22:34, Joe Cooper wrote:
> > Thoughts?
>
> My only thought is that I was baffled that the key included the method,
> when I was writing an external database to keep up with cached objects.
> It seemed unnecessary, but I assumed someone smarter than me had
> thought it through thoroughly and had a good reason for it--so I wasn't
> going to say anything. ;-)

There are a good reasons to have it there. It's very efficient for
retrieval IFF you know the method. I'm becoming convinced that we need a
two level retrieval structure - URL and metadata.

Henrik has neatly sidestepped the issue I'm facing with vary by placing
a canonicalised description of the Vary: headers into the MD5
calculations, and placing a dummy object that lists what headers to Vary
on in the store index with nothing appended. I imagine that ETag can be
done via an extension of the same - for Only-If-Match. However, getting
the list of Etag's available is a similar proposition to invalidating
all Vary: versions on a PUT.

So something needs to allow:
storeGetEntryByRequest(request_t const *)
to:
efficiently find a list of candidates that match the URL
within that list find a response that satisfies the other metadata
criteria such as ETag.

Rob