- From: Joel N. Weber II <devnull@gnu.ai.mit.edu>
- Date: Fri, 12 Sep 1997 15:28:10 -0400 (EDT)
- To: fielding@kiwi.ics.uci.edu
- Cc: jg@pa.dec.com, luotonen@netscape.com, henrysa@exchange.microsoft.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, mogul@pa.dec.com, freier@netscape.com, paulle@microsoft.com
a) expire immediately or never cache
b) expire in 15 minutes to an hour, which is essentially the same as
"immediate" but reduces some flash effects from people sharing the
same proxy.
c) expire on some date in the future (1 day/week/month), which is
typically used for resources that rotate content periodically.
If these cases are the only ones that we care about, then we can
solve these problems without having the clocks syncronized.
>From my experience, I've come to assume that clocks off by 10 minutes
are going to be normal. (In an NFS environment, it's important to
keep clocks synced so that make will work correctly, but I often
run a browser on a machine not running NFS. And if I do run NFS
on my home machines someday, I might not bother syncing the clocks with
the `real correct' time.
a) and c) will obviously work fine if clocks are off by ten minutes.
b) won't work so well. Perhaps a way of specifying time relative to
when the client recieves it, rather than an absolute time, would work
better. That way, the client and convert it to an absolute time which
will be 15 minutes (or whatever) by its clock.
It's probably too late to change the definition of a date in HTTP/1.1, but
I believe that would be an adaquate solution otherwise.
Received on Friday, 12 September 1997 12:33:28 UTC