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
