Looks like a possible RFC 2616 MUST violation. Apache cache ignores max-age cache-control directive. See attached traces for details and ways to reproduce some of the violations mentioned above. Test case IDs in the trace link to human-oriented test case description and RFC quotes, if available.
Created attachment 4365 [details] test case trace
I noticed too something strange withe the max-age header, but I think apache MUST only add a warning sayng that the result is stale. This is an example taken with muffin snoop filter, proxy.zzz.yy is a squid cache and misses, www.xxx.yy is an apache mod-proxy and hits. <begin example> HTTP/1.0 200 OK Via: 1.1 www.xxx.yy Cache-Control: max-age=600 ETag: "23e050-f13-3e1a1119" Accept-Ranges: bytes Content-Type: image/jpeg Age: 1217 Date: Wed, 08 Jan 2003 13:41:51 GMT Proxy-Connection: keep-alive Server: Apache/1.3.27 (Unix) X-Cache: HIT from www.xxx.yy X-Cache: MISS from proxy.zzz.yy Last-Modified: Mon, 06 Jan 2003 23:28:25 GMT Content-Length: 3859 <end example> Age is 1217 and max-age is 600 so it looks like squid is right and apache not but the standard says: <begin rfc 2616> If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured to override the expiration time of a response, the cache MUST attach a Warning header to the stale response, using Warning 110 (Response is stale). A cache MAY be configured to return stale responses without validation, but only if this does not conflict with any "MUST"-level requirements concerning cache validation (e.g., a "must-revalidate" cache-control directive). <end rfc 2616> However when the CacheMaxExpire on www.xxx.yy has expired mod proxy returns this: <begin example> Via: 1.1 www.bunte.t-online.de Cache-Control: max-age=600 ETag: "23e050-f13-3e1a1119" Accept-Ranges: bytes Content-Type: image/jpeg Date: Wed, 08 Jan 2003 13:58:40 GMT Proxy-Connection: keep-alive Server: Apache/1.3.27 (Unix) PHP/4.2.3 X-Cache: HIT from www.xxx.yy (with revalidation) X-Cache: MISS from proxy.zzz.yyy Last-Modified: Mon, 06 Jan 2003 23:16:03 GMT Content-Length: 4019 <end example> Again squid misses and apache returns a stale document this time revalidated and with a warning (this should probably be a warning 110). This is what the standard says: <begin rfc 2616> max-age When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency. However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response. <end rfc 2616>
oopps,this bug refers to apache 2.0 mod_cache. Anyway looks like the behaviour of Apache 2.0 is coherent with that of mod_proxy apache 1.3.27. The return code for the second example in my previous comment was "HTTP/1.0 200 OK".
Ermanno, The cache MUST treat the entity as stale. This implies that the cache MUST miss, revalidate, or add a Warning (if configured to do so). Apache does neither. Also, please note that we are talking about max-age _response_ directive (some of the requirements you quote are for max-age request directive, IIRC).
Created attachment 7028 [details] The Fix is attached. The Util_script.c, the place where the cache is read into headers_out, Cache-Control header was missed out. I have added that. Line number 594 to 596
Created attachment 7123 [details] test case trace, patched 2.0.46
After applying the changes to 2.0.46, the test case still fails. The corresponding trace is attached. We cannot test against HEAD at this time because it segfaults too often.
HEAD of which branch? HEAD of the MAIN branch is 2.1-dev. If it's segfaulting, can you give us a backtrace? But more importantly, can you test against the APACHE_2_0_BRANCH, which is 2.0.47-dev (about to be 2.0.48-dev).
AFAIK, CVS has only one HEAD :-) If my interpretation of Apache devel instructions is correct, CVS HEAD corresponds to 2.1.0-dev version of apache. The Server header emited by Apache seems to suggest that as well. I am sure the segfault cause will be removed before we have time to produce the corresponding bug report. This has happened before. We will do our best, but please note that we have to concentrate on compliance problems. We will try to test the same change against APACHE_2_0_BRANCH.
HEAD is the head of the unstable 2.1 development branch and may, on occaision, be unstable. APACHE_2_0_BRANCH is head of the stable 2.0 branch and should always be a stable base of code to test on.
Created attachment 7139 [details] hopefully same changes, unified diff format (against APACHE_2_0_BRANCH)
Created attachment 7140 [details] test case trace against patched APACHE_2_0_BRANCH
After applying the changes to APACHE_2_0_BRANCH, the test case still fails. The corresponding trace is attached.
Created attachment 7151 [details] This patch will make this work. But actually this is a defect dependent on 21392, which i have filed. Put this patch in addition to what i gave already submitted..
Created attachment 7167 [details] gdb stack trace with patch #7151
Created attachment 7168 [details] test case trace (leading to a coredump with patch#7151)
The latest patch (#7151) does make a difference -- we get a reproduceable coredump :-). Co-Advisor trace and stack trace are attached. Removing the patch prevents Apache from dumping core, but leaves the violation. Are we doing something wrong?
Note that bug 21392 (that you mentioned as related) depends on Expires header present. This bug does not. IIRC, this bug also prevents us from testing Apache against few other related RFC 2616 requirements, including max-age and Expires relationship. Hope you can nail it down!
I know this problem. But this looks like a different problem. Because, In 2.0.46, when i tried a scenario like, the server has a cache, that is stale and tries to re-validate what it has, It was dumping core even with out my any fix. I assumed that this is a defect, may be they are working on. I develop on Netware. We have something like strict memory check. So it happens every time, when i say strict memory check, all re-validation abends (core dumps) on my server. May be i will try with out my fix. And if i am able to reprocude my defect, i'll file it and get it fixed. So that we can go forward in this defect. -Srini.
I'm going through the bug db to make sure patches are findable. Please see http://httpd.apache.org/dev/patches.html
Can you test this again with 2.0.54? I believe it is fixed now.
Yes, this violation appears to be fixed in httpd-2.0.54. Thank you.