httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: mod_cache
Date Mon, 07 Mar 2005 05:14:27 GMT
--On Monday, March 7, 2005 2:03 AM +0100 Sander Striker <striker@apache.org> 
wrote:

> However, I do think you are right that ap_meets_conditions() doesn't do the
> right thing.  But that is in general, not just in this case.  It doesn't
> seem to take responses other than 2xx into account.  In those cases it
> shouldn't
> return a 304, yet it does.  We'll have to visit all the places where
> ap_meets_conditions() is called to make sure r->status is set, and check
> r->status in ap_meets_conditions() to fix this.

*nod*  This is what I was worried about.

> Luckily for us, there is more work left even in mod_cache.  Right now,
> whenever we hit a Cache-Control: no-cache in the request, the cache declines
> to handle the request, while it could be handling it (be it with a required
> validation request to the backend).  That would be a lot more efficient.
> And within bounds of the spec.

I'm not sure what you mean.  Do you mean that if we get a Cache-Control: 
no-cache, that we should attempt to treat it as mandatory revalidation of the 
content?  Interesting.  Right now, we just get out of the way.

One approach would be to remove the no-cache check and move it down into 
ap_cache_check_freshness() and make our response always be stale in this case.

> Furthermore, Cache-Control: max-age=0 or even max-age=X seems to be
> completely
> ignored.  A response is given back with an Age header with a larger value
> then
> what max-age was set to in the request.

This *should* be handled by ap_cache_check_freshness().  I'll admit that I 
haven't spent a lot of time in there.  On a cursory look, it seems that it 
should be handling this correctly.  -- justin


Mime
View raw message