Re: Sections 13.2.4 and 13.3.3

Jeffrey Mogul wrote:
> 
>     13.2.4
> 
>     Note that neither of these calculations is vulnerable to clock
>     skew, since all of the information comes from the origin server.
> 
>     13.3.3
> 
>     The arbitrary 60-second limit guards against the possibility that
>     the Date and Last-Modified values are generated from different
>     clocks, or at somewhat different times during the preparation of
>     the response.
> 
>     These two statements seem to be at odds.
> 
> They are not at odds.
> 
> The statement in 13.2.4 applies to calculations of total
> freshness lifetime (before comparison with the Age of a 
> response).  This calculation is not vulnerable to clock skew,
> because the origin server declares its intentions unambiguously.

I'm not sure that this is stated. It assumes that the expires value derives
from the same clock that the date value does. If, for example, the expires
value was set by the user saying "10 days from the file date" then it is
vulnerable to the same problem as below.

Cheers,

Ben.

> 
> The statement in 13.3.3 refers to an algorithm for deciding
> if a Last-modified time is a weak or strong validator by comparing
> it to a Date value.  Since there is no straightforward way to
> enforce a specified relationship between these two values, it
> is possible that the implied causal relationship is wrong.  For
> example, if the file system used by the HTTP server is remotely
> mounted from a NFS server with a skewed clock, the (NFS-based)
> last-modified time will be wrong.
> 
> 60 seconds is a somewhat arbitrary value, and an implementation is
> not required to use this inference rule.
> 
> -Jeff

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Received on Monday, 3 June 1996 15:56:43 UTC