Re: If-Modified-Since and forged dated

In article <95Aug16.004640pdt.2763@golden.parc.xerox.com> Larry Masinter
<masinter@parc.xerox.com> wrote:
> 
> 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.

You are forgetting that this only solves a third of the problem.

It doesn't solve the problem of two dates being exactly the
same but the file has been modified, or the problem of a file getting
modified and having it's date set into the past.  Date's alone
are not a strong enough versioning system.  And don't try and tell me 
that these don't happen.  They are as likely to happen as a file with
a date far forward, and these kinds of problems are happening all
the time.

In addition to these other two problems, by restricting dates that
have been set far forward, you are in effect disabling caching for
these files.  This is a far worse solution to adding a checksum.

lou
-- 
Lou Montulli                 http://www.mcom.com/people/montulli/
       Netscape Communications Corp.

Received on Wednesday, 16 August 1995 13:43:19 UTC