- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 10 Jan 96 15:03:10 PST
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: http-caching@pa.dec.com
I have no problem with including a set of heuristics in the spec
for normal cache behavior, with some maximum criteria as well.
However, it should also take into consideration things like
user-defined requirements for cached responses (such as the "never
check" mode of Netscape). Jeff's draft fails to consider these
because the definition of "valid" does not consider what the user
and provider want the cache to do.
I don't understand this last sentence. It is true that the definition
of "valid" in my proposal:
valid A cached entity is valid, with respect to a given
request at a given time, if it is exactly what the
origin server would return in response to that
request at that time.
says nothing about what the user or provider want. But nowhere
do I say that what the user sees must always be valid! In fact,
I specifically wrote:
- The protocol must allow users, servers, and proxies to
choose performance over correctness if they want to
(I'll address Koen's concerns over my definition of "correctness"
in a separate message, but one can assume that I mean this sentence
to still apply if "correctness" were replaced by "validity".)
For example, a client could specify the equivalent of "never check"
by sending "Cache-control: stale-max=10000000000".
And I have no idea how you could have gotten the impression that
my proposal "does not consider what the ... provider want[s] the
cache to do."
Was what I wrote really that unclear?
-Jeff
Received on Wednesday, 10 January 1996 23:08:44 UTC