Re: Improving If-Modified-Since

In article <v02120d04ac580956f14c@[198.64.246.22]> cshotton@biap.com (Chuck
Shotton) wrote:
> 
> >In article <v02120d19ac57a7ce5be9@[198.64.246.22]> 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 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.

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

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

That isn't a change from the subject.  The cache is corrupted because
of version skew, they are both tightly related.

:lou
-- 
Lou Montulli                 http://www.mcom.com/people/montulli/
       Netscape Communications Corp.

Received on Wednesday, 16 August 1995 14:07:55 UTC