W3C home > Mailing lists > Public > www-jigsaw@w3.org > January to February 1998

Re: cached resources

From: Paul Pazandak <pazandak@OBJS.com>
Date: Mon, 26 Jan 1998 11:42:47 -0600
Message-ID: <34CCCB9C.72342444@OBJS.com>
To: Jigsaw Email List <www-jigsaw@w3.org>


Yves Lafon wrote:

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

Is there a simple way within an (outgoing) requestfilter to tell if the request has
beenfilled by a
cached page from the proxy rather than a new page from the server?
Could we simply trust that _every time_we see "304 NOT MODIFIED" that the page was
retrieved from the cache? Do we need to parse the HTTP headers to get this, or is there
an
easier way to locate this message when it occurs?

Regards,

Paul.


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

   --

********************************************************************
Paul Pazandak                                      pazandak@objs.com
Object Services and Consulting, Inc.             http://www.objs.com
Minneapolis, Minnesota 55420-5409                       612-881-6498
********************************************************************
Received on Monday, 26 January 1998 12:42:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 April 2012 12:13:27 GMT