Re: HTTP Compliance: entry is stale if request has max-age=0

On Mon, 04 Oct 2010 17:06:28 -0600, Alex Rousskov
<rousskov_at_measurement-factory.com> 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
Received on Tue Oct 05 2010 - 01:33:21 MDT