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: Wed, 16 Aug 1995 15:51:25 -0500
Message-Id: <v02120d04ac580956f14c@[]>
To: Lou Montulli <montulli@mozilla.com>
Cc: Lou Montulli <montulli@mozilla.com>, Carlos Horowicz <carlos@patora.mrec.ar>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>In article <v02120d19ac57a7ce5be9@[]> cshotton@biap.com (Chuck
>Shotton) wrote:
>> 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.

As if file size is any better? You avoided answering the question, which
was why should the server be responsible for essentially maintaining the
client/proxy cache? This should be done by the client software, through
whatever means the client has at its disposal. I don't care what the
mechanism is. I just don't want to see thousands of caching clients beating
on servers because they are too lame to keep track of their own cache. If a
cached file is suspicious because of a date, a file size, or a bad
checksum, the client should discard it. Period. Forcing the server to jump
through hoops on every IMS request is contrary to the entire goal of
"server serve, clients do the work."

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

Well, that wasn't your original problem. If I recall correctly, all of this
started as a discussion about how to fix corrupted caches and detect when a
file was bad. If we're onto version skew, fine, but let's make sure we ALL
know when the subject changes.

I think that Larry summed up this entire discussion very well earlier
today. To beat this horse further is counterproductive.

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 Wednesday, 16 August 1995 13:52:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:14 UTC