Re: Improving If-Modified-Since

> 
> 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?

If it wouldn't be so, an incorrect future date would make a document
unavailable with a backwards corrected date.

> 
> >>
> >>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.

Is the content-length discarded by the proxy in every case ? Even
without transfer-encoding header ? 
 
> 
> 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.
> 
Why not keeping the Content-length and transfer encoding headers in the
cache file, and compare them against the new headers sent by the server
owning the document ? It is most likely that the transfer encoding, and
the transfer length will not change if the document itself hasn't changed.
If the transfer encoding scheme is the same, but not the content length,
it can be assumed that there's a new version of the document. If the
encoding scheme changed, we still have the Date header to check.

> 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!"
> 
> 
> 
Carlos Horowicz
MRECIC-ARNET

Received on Tuesday, 15 August 1995 11:38:15 UTC