On Thu, 2003-11-06 at 08:11, Y Jones wrote: > I am running 3.0-PRE3-20031002 in accelerator mode on port 80 with apache on > port 81. > > Here are the headers when fetching a page straight from apache: > HTTP/1.1 200 OK > Date: Wed, 05 Nov 2003 20:23:51 GMT > Server: Apache/1.3.28 (Unix) > Cache-Control: max-age=86400 > Expires: Thu, 06 Nov 2003 20:23:51 GMT > Surrogate-Control: max-age=3600, content="ESI/1.0" > Last-Modified: Wed, 05 Nov 2003 20:20:23 GMT > Connection: close > Content-Type: text/html > > It looks to me like this page should get cached for 3600 seconds at least. > > Fetching the page from the squid on the same machine a few seconds later > gives these changes/additions: > Date: Wed, 05 Nov 2003 20:20:46 GMT (date is slightly older than > above) > Expires: Thu, 06 Nov 2003 20:20:46 GMT (date is slightly older than > above) > Last-Modified: Wed, 05 Nov 2003 20:20:23 GMT (date is the same as > above)
Thats weird. Given that the processes are on the same machine. Could you file a bug please? > Age: 187 > X-Cache: HIT from www.myserver.com > Via: 1.0 www.myserver.com (squid/3.0-PRE3-20031002) > > And access.log calls it a TCP_REFRESH_HIT, instead of a TCP_HIT. > And cache.log calls it STALE, with: > entry->timestamp: Wed, 05 Nov 2003 20:20:46 GMT It is stale - the expires has passed. the Surrogate Control header overrides this. > I am using the default refresh_pattern. I am not using always_direct. > > Attempting to force a refresh of the object in the cache using: > squidclient -r -p80 -hwww.myserver.com > http://www.myserver.com/path/to/the/file.htm > ...yields a TCP_REFRESH_HIT and there is no change to "entry->timestamp" This is because the surrogate control overrides the browsers request for reloading. In a front-end scenario squid is authoritative for the content. Cheers, Rob -- GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.
signature.asc
Description: This is a digitally signed message part
