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

Re: Improving If-Modified-Since

From: Chuck Shotton <cshotton@biap.com>
Date: Tue, 15 Aug 1995 07:26:33 -0500
Message-Id: <v02120d1cac5640937b6e@[198.64.246.22]>
To: Lou Montulli <montulli@mozilla.com>, Brian Behlendorf <brian@organic.com>
Cc: Alex Hopmann <hopmann@holonet.net>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 9:25 PM 8/14/95, Lou Montulli wrote:

>In addition to supporting size=SIZE I encourage other server authors to
>do an _equals_ comparison rather than a greater than or equal comparison
>of the two dates.

Isn't this what the standard says anyway?

>>
>>Will the "size" be determined from the Content-length header or the size on
>>the cache's disk?  If the former, documents with incorrect content-length
>>headers are essentially uncacheable, as are results from CGI scripts which
>>generally don't have content-length headers.  If the latter, could there
>>be encoding problems?
>
>The size is determined by taking the current length of the document in the
>cache.  The content-length of the transfer is discarded, so encodings
>should have no effect.

I assume you anticipate this being implemented by having software simply
ask the underlying file system for a byte count of the file? This will
break between any two machines with different end of line sequences. As an
example, many servers read text files in their native format, converting
EOL sequences as they are sent to the client (proxy). This means that the
data stream as transmitted to the client (and cached) is a different size
from the actual size of the data stored on the disk at the server.

I think this problem alone is enough to make this scheme unworkable. This
will also break any checksum scheme as well. Macs, Windows, VMS, and Unix
servers all have different EOL sequences and the you can bet that the data
stream sent by a server is substantially different from the image of the
file that resides on the server's disk.

As I said earlier, the correct solution is to fix the problem with
corrupted caches. The modification date is a sufficient mechanism for
determining whether or not a document has changed, assuming both ends are
able to maintain data integrity. If the proxy server needs to maintain a
table of checksums for the files it caches in order to ensure data
integrity, that's fine. But it needn't involve the server of the original
document in determining whether or not its own cache has been corrupted.
Simple comparison of the local checksum to the local data store is
sufficient to indicate corruption.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                               StarNine Technologies, Inc.
chuck@starnine.com                             http://www.starnine.com/
cshotton@biap.com                                  http://www.biap.com/
                 "Shut up and eat your vegetables!"
Received on Tuesday, 15 August 1995 05:27:43 EDT

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