- From: David W. Morris <dwm@shell.portal.com>
- Date: Tue, 6 Feb 1996 03:01:07 -0800 (PST)
- To: Shel Kaphan <sjk@amazon.com>
- Cc: Jeffrey Mogul <mogul@pa.dec.com>, HTTP Caching Subgroup <http-caching@pa.dec.com>
On Mon, 5 Feb 1996, Shel Kaphan wrote:
> Here's another similar example that shows how this can happen without such
> inconsistent use of Expires dates (except in the expectable way):
>
> 1:00: Client A requests document X through cache C1.
> The document expires at 4:00.
>
> 2:00: Client B requests document X through cache C2.
> The document has been prematurely updated and now expires at
> 3:00. (It's a newsletter -- an unpredicted
> news event has suddenly changed
> the author's time frame for generating updates).
>
> 3:00 Client B conditionally gets X through C1.
> At this point C1 contains a different version of the document
> than client B has. B's version is stale, and C1's version is fresh.
>
> At this point, C1 can "legitimately" return its cached version, but B
> will be disappointed. There is no clock skew involved, only silly
> humans changing their minds about expiration dates. Unlikely? Maybe
> so.
In general, I would expect the extablishment of expiration values to
be policy decisions based on expectations. I think it quite likely
that any number of scenarios will exist in real human organizations
where expirations get set shorter and cause the above to occur.
The possibility is compounded if we introduce a probabalistic
expiration such as we discussed. All it takes is two
different interpretations of the same curve. A user agent
might expire early and a busy cache expire late. The problem occurs.
I can also envision applications where the content changes fairly
frequently but is applicable and hence expires over a longer interval
than the change rate. A weather MAP might be such an application.
A new map every 15 minutes, expire every hour using a normal
distribution with 1 sigma= 15 minutes.
Add to the mess a user interface to the proposed revalidate option
and we have yet another reason for a validate request in the
problematic order.
In the case where explicit or implicit revalidation results in
backleveling a resource, I assert that the user will be more than
disappointed. My wife is not terribly computer literate and would
consider such an even as yet more evidence that computers are not
friendly. She would notice the anomolie (perhaps triggered by the
long delay to reload the file). I don't think my wife is unusual.
I guess, I don't see any reason to insist that an opaque validator
not have an order property. The doesn't compromise opqueness in any
significant fashion and while it would preclude a date of the
rfc822 form from being used as a validator, it wouldn't prevent
use of a date. Or the HEX representation of the epoc date or
any other arbitrary value which satisfied the ordering rule.
I see two options:
1. Always require ordering based on LtoR comparison of ASCII
characters.
2. Making ordering optional and require a prefix on the
validator which defines the ordering rule. I would limite
such a prefix to identification of left or right padding
with 0x30 (ascii zero) to adjust lengths for comparison.
For example, the ordered validator might appear as
rp;092765AF to indicate right padding, etc.
Dave Morris
Received on Tuesday, 6 February 1996 11:25:39 UTC