>We had this problem too and so stopped using mod_disk_cache for a few months.
>I was under the impression it had been fixed and so we've >recently turned it
>back on. We're on Apache/2.2.26.
I had it happen in mod_mem_cache also, it's triggered in the main mod_cache mod.
Below is the relevant source from 2.2.24.
2.2.26 code says the same thing.
Now I can understand Apache wanting to respect CC headers and cache it even
though it normally wouldn't without the CC header, but the thing is, I honestly
don't know how to NOT set the CC header in the URL space based on the returned
status.
Is there even a way to say, if the response is != 200 (or whatever I specify),
don't add the CC header and/or set Expires? (I'm using a Location block
currently on the URL space to do the setting of these)
If there's not a way, then I think this is really dangerous behavior.
-Tony
/*
* what responses should we not cache?
*
* At this point we decide based on the response headers whether it
* is appropriate _NOT_ to cache the data from the server. There are
* a whole lot of conditions that prevent us from caching this data.
* They are tested here one by one to be clear and unambiguous.
*/
if (r->status != HTTP_OK && r->status != HTTP_NON_AUTHORITATIVE
&& r->status != HTTP_PARTIAL_CONTENT
&& r->status != HTTP_MULTIPLE_CHOICES
&& r->status != HTTP_MOVED_PERMANENTLY
&& r->status != HTTP_NOT_MODIFIED) {
/* RFC2616 13.4 we are allowed to cache 200, 203, 206, 300, 301 or 410
* We allow the caching of 206, but a cache implementation might choose
* to decline to cache a 206 if it doesn't know how to.
* We include 304 Not Modified here too as this is the origin server
* telling us to serve the cached copy.
*/
if (exps != NULL || cc_out != NULL) {
/* We are also allowed to cache any response given that it has a
* valid Expires or Cache Control header. If we find a either of
* those here, we pass request through the rest of the tests. From
* the RFC:
*
* A response received with any other status code (e.g. status
* codes 302 and 307) MUST NOT be returned in a reply to a
* subsequent request unless there are cache-control directives or
* another header(s) that explicitly allow it. For example, these
* include the following: an Expires header (section 14.21); a
* "max-age", "s-maxage", "must-revalidate", "proxy-revalidate",
* "public" or "private" cache-control directive (section 14.9).
*/
}
else {
reason = apr_psprintf(p, "Response status %d", r->status);
}
}
From: Mike Rumph [mailto:[email protected]]
Sent: Wednesday, February 12, 2014 4:54 PM
To: [email protected]
Subject: Re: [users@httpd] apache caching 400 http status?
Hello Anthony,
The discussion on the caching of 503 errors in bug 55669 may apply to this
email thread as well.
- https://issues.apache.org/bugzilla/show_bug.cgi?id=55669
Thanks,
Mike Rumph
On 2/12/2014 2:35 PM, Anthony J. Biacco wrote:
I'm running compiled apache 2.2.24 on centos 6.4
I have a URL which gets proxied to tomcat with mod_proxy_ajp.
The URL in a test scenario is producing a 400 status and content using tomcat
custom error pages.
Said URL space is cached in apache with mod_disk_cache.
Apache is caching said content and serving it out of cache.
I was under the assumption that 400 statuses were not supposed to be cached and
the 2.2 says as much.
Is this incorrect (even if a Cache-Control header is being set)?
-Tony
---------------------------
Manager, IT Operations
Format Dynamics, Inc.
P: 303-228-7327
F: 303-228-7305
[email protected]<mailto:[email protected]>
http://www.formatdynamics.com
