On Mon, 04 Oct 2010 17:06:28 -0600, Alex Rousskov <[email protected]> wrote: > HTTP Compliance: entry is stale if request has max-age=0. > > We should always do validation for requests with Cache-Control > max-age=0, even when entry age is also zero. In our case, RFC 2616 says: > > freshness_lifetime = max_age_value > response_is_fresh = (freshness_lifetime > current_age) > > response_is_fresh is always false if freshness_lifetime is zero... > > > The check code was introduced in r5998 with a "Import of fix-ranges > branch" message. The code was commented out at the time of that commit, > for reasons unknown. > > Test case: > test_case/rfc2616/noSrv-hit-stale-max-age-req
+1 on the patch. In other related bits; I think we have a documentation bug with ignore-reload. That violations if() case above it silently tests and skips for ignore-reload && max-age=0. Could you please add a debugs() message to the if() case matching the other trace cases? The test itself looks wrong to me, I would expect max-age=* all equate to a client reload request when the object is outside that age. In these cases it's unclear if a reload should be allowed despite the admin preference (as now done). Or if the client should receive a fail or stale response. My leaning is that the client should get the stale response. The admin has explicitly required a violation of HTTP and chosen to face the consequences. In 3.1+ reverse-proxies the http_port "ignore-cc" option should be used instead. Amos
