Re: 24-hour old misses

    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.
    
You asked "Did the author(s) intend for the [specified] MUST to apply
to HIT responses only?".  My answer was intended to convey what
the *current* specification requires and why, not whether it might be
a good idea to expand the specification.

Also, note that the terms "upstream" and "downstream", as defined
in RFC2616, probably mean something different than how you are
using them.  I think by "upstream" you mean "inbound" (i.e.,
closer to the origin server).

    > 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.

Remember that RFC2119, "Key words for use in RFCs to Indicate
Requirement Levels", says

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

You're right that the scenario seems like a weak reason to add
another MUST or SHOULD to the spec.

I'd be inclined to fix this problem by asking why a client that
is capable of dealing with Warnings is not "analyzing the response
age" (which seems like a basic requirement of the spec.)

-Jeff

Received on Monday, 30 September 2002 20:39:42 UTC