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

Re: If-Modified-Since and forged dated

From: Lou Montulli <montulli@mozilla.com>
Date: Wed, 16 Aug 95 16:39:16 -0700
Message-Id: <303281A4.3386@mozilla.com>
To: Shel Kaphan <sjk@amazon.com>
Cc: Lou Montulli <montulli@mozilla.com>, Larry Masinter <masinter@parc.xerox.com>, bne@bne.ind.eunet.hu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In article <199508162233.PAA14427@bert.amazon.com> Shel Kaphan <sjk@amazon.com>
wrote:
> 
> Lou Montulli writes:
>  >
>  > 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.
> 
> *I* won't try to tell you that these don't happen, though they seem to
> be evidence of bugs or human activity that it is not clear HTTP
> should try to correct for after the fact.  I can't think of a reason
> for this happening other than someone or something changing a system
> clock or deliberately falsifying a modification date. In any case, it
> doesn't seem like the responsibility of a communication protocol to
> try to figure out what's "really" going on if a server is too lame to
> get it right for itself.

With most current implementations of HTTP servers it is impossible to
"get it right for itself".  HTTP servers reference a file system
that can be changed at random.  The HTTP server can only rely
on the last modified date of a file and that date can be inaccurate.
Adding an additional size checksum allows the server to "get
it right for itself" much more often.

> 
> The percent of the time that there is going a problem like this seems
> like it must be small, certainly not worth imposing additional
> overhead on the protocol to correct for, especially if that involves
> scanning whole files for checksums.

Protocols like HTTP are not about getting is right 99% of the time,
they need to get it right 99.99% of the time.  Adding a size checksum
significatly reduces the error rate.  Adding an MD5 checksum
reduces that error rate even furture.

I don't want to require all servers to interpret size= or MD5=, but
client should be allowed to send them optionally so that
the server can use them if it really wants to make an informed
decision about sending a 304.  

Perhaps reliability is not as important to your systems as it is
to ours?  If that's the case, make your servers ignore size= and
only use the date. 

:lou
-- 
Lou Montulli                 http://www.mcom.com/people/montulli/
       Netscape Communications Corp.
Received on Wednesday, 16 August 1995 16:41:10 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:25 EDT