Bug 15866 - cache MUST treat incomplete cached response as partial
Summary: cache MUST treat incomplete cached response as partial
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cache (show other bugs)
Version: 2.0-HEAD
Hardware: All All
: P3 normal with 4 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL: http://coad.measurement-factory.com/c...
Keywords: FixedInTrunk, PatchAvailable
: 32735 (view as bug list)
Depends on:
Blocks: 50195
  Show dependency tree
 
Reported: 2003-01-07 21:55 UTC by Co-Advisor
Modified: 2011-02-12 08:13 UTC (History)
4 users (show)



Attachments
test case trace (12.67 KB, text/html)
2003-01-07 21:55 UTC, Co-Advisor
Details
Trunk patch to not cache responses whose length doesn't match the Content-length header (5.79 KB, patch)
2009-09-23 06:40 UTC, Dan Poirier
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Co-Advisor 2003-01-07 21:55:20 UTC
Looks like a possible RFC 2616 MUST violation. 
Apache caches a truncated response (which it MAY)
but does not treat it as partial (which it MUST).

See attached trace for details and ways to reproduce.

Test case IDs in the trace link to human-oriented test case
description and RFC quotes, if available.
Comment 1 Co-Advisor 2003-01-07 21:55:50 UTC
Created attachment 4362 [details]
test case trace
Comment 2 Co-Advisor 2005-06-04 00:40:25 UTC
FYI: This violation still exists in httpd-2.0.54.
Comment 3 Paul Querna 2005-06-04 01:44:45 UTC
This one doesn't have an easy solution.  The problem is that mod_proxy currently
has no way to tell mod_cache if a response terminated abnormally.  We could add
some code in mod_cache, to make sure Content-Length matches that actual length,
and invalidate the cache at that point.

The root of the problem is that the request effectively becomes non-cachable(or
at least, requiring re-validation), at the last possible moment, long after we
decided to cache the object.
Comment 4 Co-Advisor 2005-06-06 17:40:35 UTC
Yes, adding code to invalidate cache entries when Content-Length
mismatches that actual length will remove this violation and may
improve cache robustness overall. IIRC, Squid does something like
that.

A "proper" (but much more difficult) fix is to support caching of
partial responses. Very few caches are capable of that. However,
the first step would still be the detection of a partial response,
just like in the simple solution above. Thus, that code will not
be wasted.

Comment 5 William A. Rowe Jr. 2007-12-30 23:14:12 UTC
*** Bug 32735 has been marked as a duplicate of this bug. ***
Comment 6 Dan Poirier 2009-09-23 06:40:13 UTC
Created attachment 24306 [details]
Trunk patch to not cache responses whose length doesn't match the Content-length header

Here's a trunk patch.  It checks the length of the response after caching it, and if it doesn't match the Content-Length header, then drops the cache entry.
Comment 7 Dan Poirier 2009-09-24 07:26:46 UTC
Committed to trunk, r818492
Comment 8 Philip Pickett 2009-09-28 16:31:31 UTC
Can this be proposed for backport to Apache 2.2?
Comment 9 Dan Poirier 2009-09-29 05:32:22 UTC
I'm working on an alternative fix based on helpful suggestions on the development list.  Once we have something that everybody is happy with, I'll propose for backport.
Comment 10 Dan Poirier 2009-10-05 05:16:09 UTC
Backed out r818492 which blocked all caching of incomplete responses.
Committed r821763 which specifically blocks caching of incomplete
responses in mod_disk_cache.  This leaves the flexibility for other
cache implementations to implement caching of incomplete responses
correctly (per RFC 2616).  This is all in trunk.
Comment 11 Graham Leggett 2011-02-12 08:13:39 UTC
Closing as fixed in trunk, which will soon be released as v2.4.