- From: Chuck Shotton <cshotton@biap.com>
- Date: Tue, 15 Aug 1995 18:21:37 -0500
- To: Carlos Horowicz <carlos@patora.mrec.ar>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> 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 ?
The problem is that the disk storage used on the server is not the same as
the disk storage used on the client/proxy. Therefore, the ONLY way that a
server can confirm a SIZE request sent by a client/proxy is to parse the
file, doing whatever conversions it would normally do and then compute the
size of the hypothetical output stream. At this point, it might as well
just send the entire file, because the server just read it all.
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.
--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
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 16:22:10 UTC