- From: Paul Pazandak <pazandak@OBJS.com>
- Date: Mon, 26 Jan 1998 11:42:47 -0600
- 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 UTC