On 2 January 2003 16:34, Marc Elsen wrote:
> > Here: my browser has http://www.xfree86.org/isc.gif
> > in it's cache, so it asks Squid:
> > "If-Modified-Since: Tue, 08 Oct 2002 19:50:42 GMT; length=3768" ?
> > Squid does not have it in the cache (I just recreated empty cache
> > directories), so it goes to the www.xfree86.org, asks the same,
> > receives "HTTP/1.1 304 Not Modified", reports that to the browser.
> >
> > The problem is, it will go to www.xfree86.org again and again
> > whenever I visit the site as long as browser has that .gif
> > internally cached. This looks suboptimal for me. "Clear all caches
> > of all
>
> Does it ? Note that the hole process is of fetching objects
> is browser driven.
> If the browser has the object in it's cache, the only thing
> it has to be sure off , is that it has the latest version.
> So the browser must make sure that the object is fresh.
> There is no other alternative to make then to make an
> if-modified-since request to the cache.
>
> UNLESS 'freshness' information is being returned from the remote
> webserver.
> Apparently this information is not available for this object, so
> the browser and subsequent cache-chain are behaving correctly.
Maybe it is possible to translate browser's IMS request into
'fetch first 16 bytes' type request and use last-modified date
to estimate age of the object, avoiding further IMS'es going
to the Net.
I have a feeling that squid presently have no ability to cache
partial objects, and I need to code it myself if I want it.
> Checkout
>
> http://www.ircache.net/cgi-bin/cacheability.py
>
> You may want this tool usefull.
> > Okay, now I'll purge browser cache. Go for the .gif again.
> > First time, it gets cached (TCP_MISS in access.log).
> > Next time? TCP_REFRESH_HIT! From the FAQ: "TCP_REFRESH_HIT:
> > The requested object was cached but STALE. The IMS query for
> > the object resulted in '304 not modified'".
> >
> > I had similar problems when squid's box had wildly wrong
> > system date (~1992 ;), but now date is correct.
> >
> > What's even more puzzling, http://www.xfree86.org/xfree86.logo.gif
> > does NOT exhibit this. I get TCP_IMS_HIT on second and subsequent
> > accesses, which is normal. Why?! Anyone with cluebat?
>
> The only difference between the 2 cases I can see is that for
> the first object it was already in the browser cache.
> And for the second it is in the SQUID cache already,hence
> the different access states.
I'm sorry, but no. I completely killed browser cache. Look closer:
TCP_MISS/304 192 GET http://www.xfree86.org/isc.gif - DIRECT
TCP_MISS/304 192 GET http://www.xfree86.org/isc.gif - DIRECT
TCP_MISS/304 192 GET http://www.xfree86.org/isc.gif - DIRECT
*** I cleared browser cache here
TCP_MISS/200 4065 GET http://www.xfree86.org/isc.gif - DIRECT
*** isc.gif gets cached in squid
TCP_REFRESH_HIT/304 191 GET http://www.xfree86.org/isc.gif - DIRECT
*** whoops... already stale???
IMS goes to the xfree.org (BAD)
TCP_REFRESH_HIT/304 191 GET http://www.xfree86.org/isc.gif - DIRECT
TCP_REFRESH_HIT/304 191 GET http://www.xfree86.org/isc.gif - DIRECT
TCP_MISS/200 27349 GET http://www.xfree86.org/xfree86.logo.gif - DIRECT
*** logo.gif gets cached in squid
TCP_IMS_HIT/304 214 GET http://www.xfree86.org/xfree86.logo.gif - NONE
*** IMS served by squid (OK)
TCP_IMS_HIT/304 214 GET http://www.xfree86.org/xfree86.logo.gif - NONE
TCP_IMS_HIT/304 214 GET http://www.xfree86.org/xfree86.logo.gif - NONE
-- vdaReceived on Fri Jan 03 2003 - 00:37:07 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:12:25 MST