Re: store MD5 keys

It is true that we need to unify HEAD and GET, but removing the request method
won't solve the problem, only give you a whole bunch of other problems.

There is more to this than variants and ETag. You also have to consider error
messages and negative caching.

For example, assume a server does not support POST to a specific URL (not a
too uncommon thing.. most only supports POST where there is a POST handler).
Squid then negatively caches the error.

There is also the ambigouity in the RFC that allows caching of POST replies,
but nothing is said on the semantics of this reply. Is it a reply specific
for POST, or the same reply as would be seen in response to GET? (we
currently ignore positive caching of POST replies).

Regards
Henrik

Robert Collins wrote:
> I just want to run something past the list:
>
> Currently store MD5 keys include the request method in the MD5
> calculation.
>
> I think this is wrong. We end up having to build a fall-back list of
> what methods produce replies we can cache, AND having to iterate through
> all possible methods to fully flush a URL's reference.
>
> I.e. when we see a PUT we are meant to make all variants of that entity
> stale.
>
> So, for 2.6 I'd like to remove the method from the store key
> calculations, allowing much simpler logic for some of the HTTP MUST
> clauses.
>
> This cropped up when I allowed HEAD requests through the cache, and a
> HEAD response arrives that is more recent that the object we are
> validating. The GET request gets ejected, leaving only the HEAD request
> behind. Not great. I can deal with this as a special case but I'd rather
> see the core problem solved.
>
> We will need the method available for client side processing, and a list
> of the all the variants of the object... but an extension of the under
> development ETag logic to track the method as well as the MD5 should
> handle that.
>
> Thoughts?
>
> Rob
Received on Mon Sep 09 2002 - 03:18:29 MDT