- From: Lou Montulli <montulli@mozilla.com>
- Date: Tue, 15 Aug 95 20:07:33 -0700
- To: Chuck Shotton <cshotton@biap.com>
- Cc: 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.
If a server chooses to ignore the SIZE that's fine, but your arguments
are not true for most web server platforms. You are also assuming that
your bandwidth is unlimited, it is certainly not just as efficient to
send the entire file as it is to parse the whole file to determine the
size.
>
> 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
--
Lou Montulli http://www.mcom.com/people/montulli/
Netscape Communications Corp.
Received on Tuesday, 15 August 1995 20:16:39 UTC