httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul J. Reder" <rede...@remulak.net>
Subject Re: cvs commit: httpd-2.0/modules/experimental cache_storage.c cache_util.c mod_cache.c mod_cache.h mod_disk_cache.c mod_mem_cache.c
Date Fri, 24 Sep 2004 19:03:10 GMT
As I recall the problem was that, at the time the CACHE_CONDITIONAL code
actually ran and tried to install the correct filter (in or out), it was
unable to alter the filter chain in a way that would allow the filter to run.
It was able to successfully add the filter, but it apparently was added
before the current one and never got run. It simply silently failed to
return the content. There was actually a bug in the code that resulted in
the cache_conditional portion of things being avoided that I "fixed" which
then resulted in finding this out. I put a comment in the code and "broke"
it again so it wouldn't try to use the cache_conditional logic.

The issue to resolve is how to make the choice, late in the game, of which
path to follow and add the right filter *after* the current point in the
chain. This may require a single merged filter that has both paths included
and uses the cache_conditional logic for the top level code-path choice
(thus avoiding the whole filter adding issue).

Paul J. Reder

Bill Stoddard wrote:
> Graham Leggett wrote:
> 
>> Bill Stoddard wrote:
>>
>>>> Stale objects are discarded and fetched from the origin server.
>>
>>
>>
>>> So we're missing all the code to handle RFC 2616 section 13.3. We're 
>>> not violating the RFC but our cache is sure not as efficient as 
>>> possible.
>>
>>
>>
>> What the CACHE_CONDITIONAL filter did was say "if the cached response 
>> is stale, change this request to a conditional request by adding 
>> If-None-Match. If I get a 304 back, then serve my cached copy, it is 
>> fresh. If I get a 200 back (or something else), throw away my cached 
>> copy and serve the new 200 content instead".
>>
>> If the CACHE_CONDITIONAL filter is the wrong way to go about this, 
>> what is the correct way to go about this?
>>
>> So far simplifying the code is nice, but if "simplifying" means 
>> "ignore part of the RFC", then we're moving backwards. :(
>>
>> Regards,
>> Graham
>> -- 
> 
> 
> 
> Yea, I agree we lost some good function in the CACHE_CONDITIONAL filter. 
> Here is Justin's explanation:
> 
> " Also, remove the broken conditional filter code as you can't reliably 
> alter the
>   filter list once the response is started.  (Regardless, 
> cache_select_url()
>   has the freshness checks now.)"
> 
> Looking at adding the function back in.
> 
> Bill
> 
> 

-- 
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein



Mime
View raw message