httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VIS <>
Subject Re: [PATCH] fix incorrect 304's responses when cache is unwritable
Date Thu, 11 Aug 2005 00:49:24 GMT
>--On August 8, 2005 1:25:46 PM +0100 Colm MacCarthaigh <> 
>> 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?
>I've lost track of what it's supposed to do.  ;-)

I try to sort things out. Colm please correct me if I mix things up:

Colm merged his and my patch which solved the following issues:

Colms patch: If the headers for a revalidated cache entry cannot be stored
for whatever reason then remove this cache entry from the cache rather then
to try revalidating it each time. Cite from the comments of Colms patch:

/* Before returning we need to handle the possible case of an
 * unwritable cache. Rather than leaving the entity in the cache
 * and having it constantly re-validated, now that we have recalled 
 * the body it is safe to try and remove the url from the cache.

My patch: It tries to delete cache entries for which a non cacheable
response (most focused on 404's) was delivered during revalidation.
Basicly this was already implemented, but 

- the remove_url function of mod_disk_cache was empty
- it turned out that error response sometimes bypass the CACHE_SAVE filter
  (canned error responses) or do not call it with the original request.

Those things are fixed by my patch which I developed during ApacheCon
after the discussion with you, Paul and Sander.

Colms patch relies on the implementation of remove_url in mod_disk_cache
to get the file really deleted.

Later on I send a patch to the merged patch which

- Moves some logging messages which produces misleading messages
- Also removes the directory structure of the cached files as
  far as possible. As Colm pointed out correctly leaving the empty
  directories on the disk is a pain for the filesystem, so they 
  should be removed.

Don't hesitate if you have further question or like to have this
patch broken in different chunks for better reviewing / commiting :-).



View raw message