Bug 52120 - mod_cache edge case: uncacheable 304 sends cached body, but not cached headers
Summary: mod_cache edge case: uncacheable 304 sends cached body, but not cached headers
Status: REOPENED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cache (show other bugs)
Version: 2.2.22
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-01 15:34 UTC by Graham Leggett
Modified: 2012-08-08 08:53 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Graham Leggett 2011-11-01 15:34:57 UTC
When an attempt is made to freshen a stale entry in the cache, and the 304 Not Modified response from the backend contains no ETag, no Last-Modified, and no Cache-Control header, the following code path is followed:

X-Cache-Detail: "conditional cache hit: 304 was uncacheable though (s-maxage or max-age zero and no Last-Modified or Etag; not cacheable); entity removed" from ...

In this case, because the 304 is technically uncacheable, we send the cached copy once and invalidate the entry. What we don't do however is send the original cached headers, just the headers from the 304, and in the process we see headers like Content-Type being lost or replaced.
Comment 1 Graham Leggett 2011-11-12 21:27:08 UTC
Fixed on trunk in r1201331.
Comment 2 Roy Badami 2012-08-02 13:14:06 UTC
As far as I can see, this fix was never merged into the 2.2.x branch and although the circumstances to trigger this bug are very specific, its effects can be quite nasty when it manifests.

The failure to merge headers means that entity header fields (which are not included in a 304 response) are not sent to the client.  In the case of an object with a Content-Encoding such as gzip, this results in a gzipped body being returned to the client without the header specifying the content encoding (hence resulting in the client receiving data it is unable to interpret).

The code that that contains the error was introduced to trunk in r1001884 to fix PR45341, and the current PR (PR52120) was fixed in trunk in r1201331, so any release that contains the r1001884 fix but not the r1201331 fix will suffer from PR52120.

For the case where the request we are handling was in fact an if-modified-since request, the old, pre-r1001884 code would have done the right thing, so this is a regression in 2.2.18.  It might therefore be worth considering backporting r1201331 to the 2.2.x branch.

r1001884 was backported to 2.2.x branch in r1068313 and 2.2.18 is the first 2.2.x tag that contains the fix (and therefore this regression).

2.4.x was branched from trunk r1200449, so already contained the r1001884 fix, and r1201331 was merged into 2.4.x as r1201332 prior to 2.4.1 being tagged, so no 2.4.x release suffers from this problem.

roy
Comment 3 Roy Badami 2012-08-03 11:01:53 UTC
See also https://bugzilla.redhat.com/show_bug.cgi?id=845532