Re: Improving If-Modified-Since

In article <v02120d19ac57a7ce5be9@[198.64.246.22]> cshotton@biap.com (Chuck
Shotton) wrote:
> 
> At 8:07 PM 8/15/95, Lou Montulli wrote:
> 
> >> The point I was trying to make is that size is meaningless between any two
> >> machines when text files are being compared. CR/LF on a Windows box may be
> >> stored as LF only on a Unix host, or CR on a Mac may be converted into
> >> CR/LF for transmission. This means that the original file on the server is
> >> a physically different size than the file transmitted to the client/proxy,
> >> and that the cached file size on the proxy may be an entirely different
> >> size than the content-length.
> >>
> >> File size is essentially useless as a mechanism for determining whether or
> >> not a cached file is the correct version.
> 
> >Your facts don't support your conclusion.  If linefeed conversion is
> >performed by the server then it should be done consistantly, you can
> >therefore always compute the eventual size of the object by parsing the
> >file.  If a proxy modifies the file in any way then it needs to remember
> >it's original size.
> 
> Lou, why are you forcing this computation on the server? The whole problem
> of corrupted or stale caches is a CLIENT problem and the computation should
> happen there. Why should a server be forced to read and translate every
> byte of a file, just so it can calculate the content-length for a IMS
> request from a client that is trying to use file size to determine file
> "sameness"? This is extremely burdensome on the server and shouldn't be the
> server's job.

This is where you are completely wrong.  In every case of cache corruption
that I have seen it has always been caused by server errors.  Dates
are simply not a strong enough versioning system to prevent lossage.

> 
> Here is an alternative to this whole "size" thing. Let's start with an
> assumption. You may not agree with it, but my experience shows otherwise.
> Let's assume that for any client/server pair, the two machines store the
> same text file with different sizes because of differences in EOL
> conventions. That means that the ONLY common size they can have is the
> content-length that the server reports. Since this requires action on the
> server to compute, it isn't an acceptable mechanism. SO, why not do the
> following?
> 
> When a server sends a file, the client should make sure that it received at
> least content-length bytes of data. If it doesn't receive the complete
> file, it can still display the file, but shouldn't cache it. If the client
> DOES receive the required number of bytes, it should compute a checksum for
> the file and cache the contents. Future requests for the file can simply
> use the existing IMS syntax to retrieve new versions based on modification
> dates. If dates match, the client can verify that the file in the local
> cache is uncorrupted simply by recalculating and comparing the checksums.
> All the work for this is done by the client, no server modifications are
> required, and no wasted CPU cycles are spent on the server calculating
> content-length values for a file that won't be transmitted.

This does nothing to solve the problem.  The problem we are trying
to solve is not local cache corruption, it is version skew. 

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

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