Under a very specific set of circumstances, apache proxy will not serve
the correct headers for cached content. This was observed under 2.2.29
and seems to exist in the 2.2.31 release.
The problem occurs when a client revalidates content that is both
already cached on the client, and on the proxy. Revalidation is
requested by the client via the If-Modified-Since header. If the
upstream webserver responds to the revalidation with a 304 Not Modified
that also contains headers indicating non-cacheable content, the proxy
will serve its cached content to the client, but without the appropriate
headers. This can result in errors on the client side as content
encoding and content type information is lost.
The specific circumstance is described in a comment in mod_cache:
/* Hold the phone. Some servers might allow us to cache a 2xx, but
* then make their 304 responses non cacheable. This leaves us in a
* sticky position. If the 304 is in answer to our own conditional
* request, we cannot send this 304 back to the client because the
* client isn't expecting it. Instead, our only option is to respect
* the answer to the question we asked (has it changed, answer was
* no) and return the cached item to the client, and then respect
* the uncacheable nature of this 304 by allowing the remove_url
* filter to kick in and remove the cached entity.
*/
The code proceeds to push the cached content onto the bucket brigade but
neglects to apply the matching cached headers.
Originally I thought the solution would be to simply add the cached
headers but in the 2.4.x branch, it seems that this case is handled by
re-requesting the resource without the conditional. Should this code be
backported into the the 2.2.x branch ?
