Re: 24-hour old misses

Jeff,

	Thanks for a clarification! It looks like the answer depends on
whether "it is interesting" to add this Warning to a miss. That is, whether
there is any "use" in attaching such a Warning. You think it is not useful
because cache heuristics do not apply to misses. I think one could consider it
being useful because the Warning could be about upstream cache's heuristic,
not about the cache adding a Warning. See below.

> I can't see any reason to Warn anyone on a miss that creates
> a new cache entry with a heuristic expiration lifetime

The only reason I can think of is the "garbage in, compliance out" principle:
the proxy should improve the "quality" of responses it forwards.  Imagine that
there is a non-HTTP/1.1 cache upstream that cached the response for more than
24 hours. Imagine that the requesting client agent supports Warnings but does
not analyze response age. If a compliant proxy adds a Warning (that the
upstream cache should have added, but did not!), the user will get a useful
Warning.

The above scenario is quite artificial, of course. I am not sure whether it is
good enough to say that the MUST in question should apply to misses.

Thank you,

Alex.

-- 
                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance

On Fri, 27 Sep 2002, Jeffrey Mogul wrote:

> Catching up (slowly!) on old email:
>
> Alex writes:
>
>     RFC 2616, Section 13.2.4 "Expiration Calculations" contains
>     the following MUST:
>
>        The cache MUST attach Warning
>        113 to any response whose age is more than 24 hours if such warning
>        has not already been added.
>
>     The context of that MUST is expiration calculation and, hence, cache
>     hits. On the other hand, attaching a Warning to misses may help in
>     case there is a non-1.1-compliant cache upstream.
>
>     Did the author(s) intend for the above MUST to apply to HIT responses
>     only?
>
> Again, I believe I wrote this part.
>
> Take a look at section 14.46 (Warning) which defines the specific
> warning-value mentioned above:
>
>    113 Heuristic expiration
>      MUST be included if the cache heuristically chose a freshness
>      lifetime greater than 24 hours and the response's age is greater
>      than 24 hours.
>
> True, it's not explicit here that this applies only to cache
> hits.  But it would only be interesting on a miss if the cache's
> heuristic choice for a freshness lifetime were to be inserted
> into the forwarded response header.  In other words, the origin
> server sent no Expires header (or something equivalent, such
> as a max-age directive) and the proxy guessed at one and then
> added an Expires header to the response.
>
> But look at section 13.5.2 (Non-modifiable Headers), which says
> that
>
>    A transparent proxy MUST NOT modify [the Expires field in
>    a response, but MAY add one] if not already present. If an
>    Expires header is added, it MUST be given a field-value identical to
>    that of the Date header in that response.
>
> so (by that MUST) the cache isn't allowed to propagate its
> heuristically-chosen freshness lifetime to anyone else.
>
> Since section 13.5.2 doesn't discuss Cache-Control, this looks
> like a loophole in the spec (e.g., the cache could perhaps
> add "Cache-control: max-age=1000000000") but I would hope that
> proxy cache implementors aren't actively looking for loopholes
> of this sort.
>
> Probably, therefore, you should read the relevant part of 14.46
> as if it said:
>
>    113 Heuristic expiration
>      MUST be included if the cache heuristically chose a freshness
>      lifetime greater than 24 hours for a cache entry, the response
>      is taken from that cache entry, and the age of the response is
>      greater than 24 hours.
>
> I can't see any reason to Warn anyone on a miss that creates
> a new cache entry with a heuristic expiration lifetime, given
> that the cache shouldn't be propagating these heuristic values
> towards the client.
>
> -Jeff
>

Received on Saturday, 28 September 2002 00:19:53 UTC