Re: [PATCH] fix incorrect 304's responses when cache is unwritable

[Paul Querna <ch...@force-elite.com>]

Justin Erenkrantz wrote:
> --On August 11, 2005 10:21:37 AM +0100 Colm MacCarthaigh
> <co...@stdlib.net> wrote:
> 
>> On Wed, Aug 10, 2005 at 03:38:17PM -0700, Justin Erenkrantz wrote:
>>> --On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh <co...@stdlib.net>
>>> wrote:
>>>
>>> > O.k., I've merged our two patches, but I've changed a few things, tell
>>> > me if there's anothing you think is wrong;
>>>
>>> Would you mind writing up a log message for this patch?
>>
>> No problem;
>>
>>     Fix incorrectly served 304 responses when expired cache entity
>>     is valid, but cache is unwritable and headers cannot be updated.
>>     Submitted by colm stdlib.net
>>
>>     Remove entities from the cache when re-validation receives a
>>     404 or other content-no-longer-present error.
>>     Submitted by ruediger.pluem vodafone.com
> 
> Thanks!  I've committed this in r231486, r231487, and r231488.  I
> re-split them up to make it easier for people to review the commits.
> 
> However, there remains an issue in mod_disk_cache's remove_url: I don't
> think it properly handles removing the Vary condition files.  I went
> ahead and committed it because it gets us closer to the desired solution.
> 
> The code will remove the header file and the disk file; but it also
> likely needs to go up a 'level' and remove all variants.  Because if we
> get a 404 on a varied entity, it also means that all variants should be
> removed, no?
> 
> I think what this means is that we need to recompute the hash - verify
> that it either meets the 'base' URL (we're done then), or we need to
> then go through and wack all of the varied headers/bodies and such. 
> Now, I *think* it's possible after Paul's latest rewrite to just wack
> some subdirectories - but I'm fuzzy on this.  (Paul??)

No need to recompute the hash.  Just rm -rf <hash>.vary, which is a
directory. Inside that directory is another layer of hashes, but thats
only based on the varied headers...

Anyways, best path would be to atomically rename the .vary to a tempdir,
and then recursively delete it.

-Paul