W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1995

Re: If-Modified-Since and forged dated

From: Larry Masinter <masinter@parc.xerox.com>
Date: Wed, 16 Aug 1995 00:46:34 PDT
To: bne@bne.ind.eunet.hu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <95Aug16.004640pdt.2763@golden.parc.xerox.com>
If we have a currently working and then someone says "I have a
problem, users complain about the following bug: bzzzt" and then "I
propose the following solution: sssss" then it's up to us to decide:

1) Is bzzzt really a problem?
2) Does sssss actually solve the problem?
3) Is sssss the best solution? In particular, can the
   problem be solved without changing the protocol?
I think in the case of
	bzzzt = 'file has bad date in the future' 
	sssss = 'add ; length=nnnn to if-modified request'

The answers are
(1) yes: it's a problem. We've all seen it, know that it has multiple
    causes which are out of our control.
(2) usually: except when the length is wrong, or hard to compute, or
    the document is dynamic, or has a different EOL convention and is
    translated on the fly; we've identified some exceptions.

However, I believe that 
(3) is false: the problem can be solved without changing the protocol,
    as I outlined in a previous message:

* A server encountering a file with a modification date in the future
  (according to the server's current time) should not send the future
  'last-modified' date.
* A proxy or cache shouldn't save a document with a future
* A client and any proxies along the way should remember the exact
  last-modified (to the second) with which the document was delivered,
  no approximations, and independent of any local time settings.

Let us also assert that HTTP server and caches on the Internet should
try to keep correct time.  There are widely available implementations
of (S)NTP for most machines. I urge everyone who has a web site about
'available HTTP servers' to also point to NTP/SNTP implementations.

If these rules are followed, the only case where a document will be
mis-cached because of date lossage would be where the file date was in
the future but the file content has has been changed and the date set
back, the server date was in the future but has been reset to the
present, and the cacher date was in the future but has now been reset.

The simplest workaround to that would be for the cache to
(aggressively) treat as 'expired' any item for which the cache date is
after the current date; if the cacher's date gets reset toward the
past, for example, it would be good practice to immediately clear any
data that was cached with a future date.
If the problem 'bzzzt' is something else (file system or data
transmission errors in the server or cache) then 'length' certainly
won't solve the problem, and anything other than checksums at proxy
and server sites also seems like overkill.  Let's understand the
nature of the kinds of problems we're trying to solve before we
engineer a fix.
Received on Wednesday, 16 August 1995 00:49:01 UTC

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