Re: cached resources

On Fri, 23 Jan 1998, Paul Pazandak wrote:

> 
> 
> Paul Pazandak wrote:
> 
> > Paul Pazandak wrote:
> >
> > > Yves Lafon wrote:
> > >
> > > > On Thu, 22 Jan 1998, Gil Hansen wrote:
> > > >
> > > > > How can one tell if a resource being downloaded is obtained from the cache
> > > > > or from the remote host?
> > > >
> > > > If Jigsaw give the resource from the cache, the ingoingFilter of
> > > > CacheFilter will return a Reply, you can use that.
> > > > Another thing is to detect the Age: 0, but clearly, it is a hack :)
> > > >
> > >
> > > According to the docs ingoingFilter procesing should stop if a non-null Replyis
> > > returned. Shouldn't this mean that no other ingoingFilters are called when the
> > > CacheFilter returns a non-null Reply? In our test cases, the ingoingFilters are
> > >
> > > still being called.
> >
> > Some additional info: In the http-server.props the line
> > w3c.www.protocol.http.filterslists CacheFilter first. The code in HttpManager DOES
> > appear correct however, and
> > SHOULD stop processing other filters if the CacheFilter (or any filters) returns a
> > non-null
> > response.
> >
> > This would imply that the CacheFilter is the last filter being processed. ...I'll
> > have to check
> > this out.Sorry... I'm still in a daze from a nasty flu. Yes, one should be able to
> > change theorder of filters in the http-server.props file, as long as jigsaw
> > doesn't crash if the
> > CacheFilter doesn't have to be listed first. (will it break jigsaw?)
> >
> 
> As it turns out the filtering is working fine! The problem was our assumptions ofhow
> the cache works (and, in turn, how HTTP works). E.g., a colleague noticed
> that after first loading a page composed of several gifs, etc. a reload doesn't
> appear
> to take as long. This gave us the impression that the cache was being used. Could
> you explain what happens when a reload occurs? What happens when the server
> returns a "304 NOT MODIFIED"?.

The cache knows that it can hold the resource for a specified number of 
seconds. By default it is one day. After the expiration of the resource, 
the Cache tries to revalidate the resource. (If-Modified-Since is added 
in the request). Then if the remote server answers with "304 NOT 
MODIFIED", the resource is served from the cache and the cache updates 
the age and freshness info according to the headers sent by the server 
(or kept and reinitialized if no more headers are there... This is not 
true in the current version but the next releas has the correct behaviour).
In case of failed revalidation the resource is fectched again and 
replaced in the cache.

      /\          - Yves Lafon - World Wide Web Consortium - 
  /\ /  \                Architecture Domain - Jigsaw
 /  \    \/\    
/    \   /  \   http://www.w3.org/People/Lafon - ylafon@w3.org

Received on Monday, 26 January 1998 12:04:29 UTC