DO NOT REPLY [Bug 15869] - cache ignores max-age cache-directive

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15869>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15869

cache ignores max-age cache-directive

scaglione@starnetone.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary| cache ignores max-age      |cache ignores max-age cache-
                   |cache-directive             |directive



------- Additional Comments From scaglione@starnetone.de  2003-01-08 14:12 -------
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>

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org