W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Issue List: CACHEDATE

From: Shel Kaphan <sjk@amazon.com>
Date: Wed, 14 Feb 1996 09:29:00 -0800
Message-Id: <199602141729.JAA21800@bert.amazon.com>
To: "Franz J. Hauck" <fjh@cs.vu.nl>
Cc: Larry Masinter <masinter@parc.xerox.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Franz J. Hauck writes:
 > If one of the parts is fetched from another server using HTTP again,
 > then we would like to use again an I-M-S header to check the part's
 > modification time. We only could use the same I-M-S header as for the
 > composed document because the original modification time of the part is no
 > longer available. So, the I-M-S time is the modification time of the composed
 > document which is equal or *later* to that of the part originally retrieved.
 > In this case we would like to know whether the document changed since exactly
 > *this* time. At *this time* it was apparently not modified as we used it to
 > compose the document.
 > --Franz

What if the document part changed during the time interval between
you first fetched it and the time you composed and sent
the compound document?  Then you are not going to detect that
change if you send a conditional request containing the last modified
date of the compound document.

I would claim that if you don't have the original last modified date of the
document part that you have to fetch indirectly from another server,
then you should not be using the conditional GET mechanism.

One problem is clock skew.  If only last modified dates are used in
such requests, there is no issue with clock skew, because the only
clock in question is the origin server's.  If the I-M-S date in the
request is constructed by the requestor, then any difference between its
clock and the server's clock may make the server do the wrong thing.
Whether this matters or not is application dependent.  This is one of the
reasons I tend to prefer the "opaque validator" approach.

Received on Wednesday, 14 February 1996 09:34:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:16 UTC