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 19:29:17 -0500
Message-Id: <v02120d09ac5838de1e3c@[]>
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
At 2:05 PM 8/16/95, Lou Montulli wrote:
>In article <v02120d04ac580956f14c@[]> cshotton@biap.com (Chuck
>Shotton) wrote:
>> >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 isn't forcing the server to do anything.  Adding a size simply
>helps the server to make the correct decision about sending a 304
>or not.  Currently servers are making wrong decisions because it
>cant tell if the file has changed becaused dates are not strong
>enough by themselves to do an adequate job of versioning.

Let's try this one last time. Lou, do you agree or disagree that for any
two CPUs, they may have different size representation for the same data
stream due to EOL differences and or differences between the transmitted
content-length and the number of bytes stored on the disk? If this is the
case (and it IS in many implementations), then using size will NEVER work.
The client will cache the file with one size, the server will compare it to
another "size" and the cached file will always appear to be modified or

The only way to solve this problem is to normalize the "size" to be the
content-length instead of the number of bytes stored on disk on either end
of the connection. This means that the server will have to read and
translate the file to recompute the content-length size whenever it is
requested. Since this is a CPU and disk I/O intensive process, it places a
burden on the server that we should try to avoid. You seem to be ignoring
this flaw in the IMS "size" discussion and it is a fatal flaw.

>> 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."
>You seem to be forgetting that "jumping through hoops", as you put it,
>is going to save the server time in the long run.  Remember, bandwidth
>is not free.

And neither is CPU time or disk I/O. These are much more limited on a
server handling lots of parallel requests than the net bandwidth on many

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 17:30:19 UTC

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