httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davi Arnaut <>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Thu, 14 Sep 2006 11:54:53 GMT

On 14/09/2006, at 05:08, Issac Goldstand wrote:

> This looks familiar.  I seem to remembering seeing patches for this a
> few months back.   Were they not committed to trunk?  If not, is there
> any reason why not?  I'd hate to spend serious time making  
> modifications
> only to have to redo the work when this (pretty major) patchset gets
> committed...

Probably because I have not yet submitted it for inclusion and it's  
not finished.
A new cache-dev branch would be really nice - hint hint :)

Davi Arnaut

> Davi Arnaut wrote:
>> On 13/09/2006, at 16:29, Issac Goldstand wrote:
>>> Hi all,
>>>   I've been hacking at mod_cache a bit, and was surprised to find  
>>> that
>>> part of the decision to serve previously cached content or not  
>>> was being
>>> made by the backend provider and not mod_cache; specifically, the
>>> expiration date of the content seems to be checked by  
>>> mod_disk_cache (as
>>> part of open_entity), and if the provider check fails, mod_cache  
>>> doesn't
>>> even know about the entity (and therefore, in the case of a caching
>>> proxy,  can't treat it as a possibly stale entity upon which it  
>>> can just
>>> do a conditional GET and possibly get a 304, rather than requiring
>>> mod_proxy to rerequest the entire entity again).
>>> When I originally started looking at the family of cache modules, I
>>> assumed that all of the decision-making logic would be in mod_cache,
>>> while the mod_xxx_cache providers would be "dumb" file-stores (at  
>>> least,
>>> as far as mod_cache is concerned).  Is this not the case?
>> I'm working on this. You may want to check my proposal at
>>> If it is, would patches be acceptable if I have the time to try to
>>> rectify the situation (at least somewhat)?
>> I'm still working on it, things may change radically.
>> -- 
>> Davi Arnaut

View raw message