Re: [squid-users] TCP_REFRESH_HIT instead of TCP_HIT?

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