Justin Erenkrantz wrote:Sander Striker wrote:
[...]
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?
Exactly.
Interesting. Right now, we just get out of the way.
Right. We don't have to AFAUI, as long as we revalidate.
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.
*nod*
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.
That's what I initially thought when I glanced over it. Then I started wondering why headers are retrieved from h->req_hdrs, instead of r->headers_in. I noticed we save the request headers of the request that got a resource into the cache. Are we maybe mistakenly using those stored headers instead of the ones from the current request? I need to go over the code, but this is what popped into my head on first glance.
Sander
