Re: [squid-users] TCP_REFRESH_UNMODIFIED instead of TCP_IMS_HIT? "Revalidation failed"

 On Tue, 29 Nov 2011 15:20:04 +0100, David Wojak wrote:
> Hi all!
>
> First, I am pretty new to proxies, so please bare with me if I'm
> doing something completely wrong. What I want to do:
>
> I have a VPN tunnel between two sides and a server serving java
> webstart jars on one side and I want to cache these on the other
> side.
> Because the jars should always be the same as on the original server,
> I want them to be stale all the time, so that squid checks the last
> modified date and returns the jar from cache only if the dates are
> equal. So far so good.

 No, this is not good use of HTTP. try sending the must-revalidate cache
 control option instead of old date. Possibly also a max-stale= value to
 determine how stale the reply is allowed to be on failure cases.

>
> What I have done:
>
> I used the standard squid (3.1.16) config on my gentoo system and put
> a refresh_pattern instead of the default refresh_patterns (I only
> want
> to cache jars):
>
> refresh_pattern -i \.(jar)\??(.*?)$ 0 0% 99999 reload-into-ims
> refresh-ims
>
> and set the following options:
>
> coredump_dir /squid_cache
> cache_replacement_policy heap LFUDA
> cache_dir ufs /squid_cache 2000 16 256
>
> maximum_object_size 256 MB
>
> Testing with a browser: The first time I request a jar I get X-Cache:
> MISS and X-Cache-Lookup: MISS which is perfectly fine but after that
> it gets interesting:
>
> HTTP/1.0 200 OK
> Date: Tue, 29 Nov 2011 13:37:59 GMT
> Content-Type: application/java-archive
> Content-Length: 66245
> Last-Modified: Tue, 29 Nov 2011 12:21:04 GMT
> Server: Jetty(6.1.16)
> Warning: 110 squid/3.1.16 "Response is stale", 111 squid/3.1.16
> "Revalidation failed"
> X-Cache: HIT from proxytest
> X-Cache-Lookup: HIT from proxytest:3128
> Via: 1.0 proxytest (squid/3.1.16)
> Connection: keep-alive
>
> Why do I get a "Revalidation failed"? I took a look at the headers
> between proxy and original server -> the original server sends a HTTP
> 1.1 304. So the revalidation should succeed, right? If I take a look
> at the squid log, it says:
>
> 1322573879.858 8 192.168.100.215 TCP_REFRESH_UNMODIFIED/200
> 66658 GET
> http://bla.bla.bla:8080/afdc3604/lib/commons-logging-1.1.1.jar -
> DIRECT/192.168.100.199 application/java-archive
>
> So I get the jar file not from cache, but DIRECT from the original
> server. Why? The file is unmodified. Shouldn't I get a TCP_IMS_HIT?
>
> If I change the refresh_pattern so that the file is not stale at any
> time I get it from cache just fine, so cache is working basically.
> But
> the revalidation just doesn't work and I have no idea why?
>
> Any hints?

 We had a bug a while back about the Warning being added in the wrong
 place. I'm not recalling clearly if that got fixed or not before 3.1.6.

 Either way, if your 304 is emitted indicating an already stale object
 the warnings are both correct. The object is stale of course. But also
 the revalidation is required to produce a new fresh object with 2xx
 status, an indication that object is currently fresh with 304 status, or
 a 4xx error. Returning a 3xx with invalid freshness information is a
 failure. Your Squid is constantly running error recovery operations on
 these 304, thus the Warning and need to use refresh_pattern '99999' to
 "fix" the cache timing errors.

 Amos
Received on Wed Nov 30 2011 - 00:32:11 MST