Re: Clock skew and the importance of clock synchronization in HTTP servers.

Clock synchronization is definitely important for correct caching,
and can be critical for some applications, but we also need to be
realistic in gauging the problem.  Normal browsing behavior across
an open Internet is not sensitive to small clock skew, since the
expiration behavior of resources tend to be one of

   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.

Although there is no way for me to quantify that empirically, I'd bet
that reflects the caching needs of more than 99% of HTTP responses that
include expiration times, which itself is an extremely small portion of
all HTTP responses.

Likewise, it is extremely rare for the clock time on the user agent
to have any adverse impact on a cache-friendly application.  The reason
being that most freshness criteria are intended to prevent a first-time
viewer from seeing someone else's stale content, as opposed to a
previous viewer seeing the same content twice.  Note that the predominant
setting for browser caches is "check once per session", and the user
can override that behavior using the Reload button (or its equivalent).

There do exist applications of HTTP for which synchronization and
cache transparency are very important, but it is also assumed that those
same applications will take extra effort to ensure that clocks are
synchronized (since these are primarily intranet applications, that is
actually possible), or at least that they will not be affected by lack of
synchronization.  Such applications cannot allow an HTTP/1.0 application
to cache its responses, regardless of clock skew.

It is critical that HTTP allow the application to determine the caching
requirements rather than hard-code it into the protocol itself.  The
most important thing for the protocol to do is to fully and accurately
describe the data being transferred, so that no application is fooled
into thinking it has one thing when it actually has something else.

It is still a good idea to recommend installation of time synchronization
software along with the server docs, but things are not as bad as they seem.

.....Roy

Received on Friday, 12 September 1997 07:23:13 UTC