Justin Erenkrantz wrote:
--On Thursday, September 23, 2004 8:17 PM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
Justin Erenkrantz wrote:
This little gem causes a regression. Because cache-handle is left
NULL,
we never cleanup stale entries in the cache (in cache_save_filter).
Once
[EMAIL PROTECTED] wrote:
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.)
How does cache handle responses that are stale?
Are these objects revalidated
Graham Leggett wrote:
[EMAIL PROTECTED] wrote:
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.)
How does cache handle responses that are stale?
Are
Bill Stoddard wrote:
Graham Leggett wrote:
[EMAIL PROTECTED] wrote:
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.)
How does cache handle responses
Bill Stoddard wrote:
Are these objects revalidated (ie If-None-Match) or are the objects
discarded and fetched again from scratch?
Stale objects are discarded and fetched from the origin server.
Hmmm... that's quite a performance hit - suddenly what should be 304's
with no bodies are suddenly
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
--On Friday, September 24, 2004 11:39 AM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
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.
Put it this way: we were violating the RFC because our Expires
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
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
[EMAIL PROTECTED] wrote:
jerenkrantz2004/09/21 15:56:23
Modified:.CHANGES
modules/experimental cache_storage.c cache_util.c
mod_cache.c mod_cache.h mod_disk_cache.c
mod_mem_cache.c
Log:
Fix Expires (freshness)
ap_get_module_config(r-request_config,
cache_module);
-rv = cache_generate_key(r,r-pool,key);
+rv = cache_generate_key(r, r-pool, key);
if (rv != APR_SUCCESS) {
return rv;
}
/* go through the cache types till we get a match */
--On Thursday, September 23, 2004 2:55 PM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
This little gem causes a regression. Because cache-handle is left NULL,
we never cleanup stale entries in the cache (in cache_save_filter). Once
CacheMaxExpires hits, the stale entry will never be garbage
Justin Erenkrantz wrote:
--On Thursday, September 23, 2004 2:55 PM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
This little gem causes a regression. Because cache-handle is left NULL,
we never cleanup stale entries in the cache (in cache_save_filter). Once
CacheMaxExpires hits, the stale entry
--On Thursday, September 23, 2004 8:17 PM -0400 Bill Stoddard
[EMAIL PROTECTED] wrote:
Justin Erenkrantz wrote:
This little gem causes a regression. Because cache-handle is left NULL,
we never cleanup stale entries in the cache (in cache_save_filter). Once
CacheMaxExpires hits, the stale entry
14 matches
Mail list logo
