- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 21 Dec 95 11:48:30 PST
- To: "Daniel W. Connolly" <connolly@beach.w3.org>
- Cc: http-caching@pa.dec.com
>(2a) The protocol must ALLOW correct caching, in which the user is
>guaranteed to see a valid copy of an object unless some network failure
>prevents it.
Hmm... this begs the question of what's valid, which can only
be answered by a spec or model. I agree with the goal in
principal, but we'll have to see what the model looks like.
Probably I would define "valid" as
What the origin server would provide if it received the
request at approximately this instant.
Without some sort of locking mechanism (which I don't think we
can expect), it's probably not possible to be more specific.
There's also a question of terminology. To be consistent with
the HTTP spec, I'd say "valid entity representing a resource"
rather than "valid copy of an object." In order to have
an effective discussion, this is pretty important.
Agreed. In fact, we will need agree upon exactly what constitutes
the unit of caching. "Valid entity representing a resource" might
not be exactly right; I would expect we would have to include some
subset (at least) of the response headers. This is already on my
list of "issues".
>(2b) The protocol must ALLOW users, servers, and proxies to choose
>performance over correctness if they want to, but must not force
>them to do so.
Hmm... that's not the way I'd word it, but I think I agree.
What you're saying is that in some cases, you'll get something
different from a caching proxy than what you would have gotten
by going to the origin server, and that's OK. I think the
thing to do is to define correctness in such away that this
is part of the deal, not to allow proxies to be "incorrect"
with respect to the protocol we make up.
Exactly. Perhaps a better wording is
The protocol must ALLOW users, servers, and proxies to choose
to obtain or provide an invalid copy if they want to, but must
not force them to do so or to do so without their consent.
-Jeff
Received on Thursday, 21 December 1995 19:55:46 UTC