>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:mike.rumph@xxxxxxxxxx]
Hello Anthony, On 2/12/2014 2:35 PM, Anthony J. Biacco wrote:
|