- 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