> You mean removing it has no effect on the HIT/MISS result and status? > You should expect just about everything to be a MISS when that QUERY > setup is used. > > That whole QUERY definition is a redundant pattern. > => the second value 'ig?' is a complex way of writing 'i'. > => the letter 'i' by itself is a sub-pattern of all the other > patterns > in that ACL. So they do not add anything by their presence. > > Meaning ... every URL which contains the letter 'i' anywhere in its > path > section will *not* be cached or served from cache. 100% of your test > URLs contain match that pattern. > > > no_cache deny QUERY > > Remove the "no_" portion of that. It was deprecated back in squid-2.2 > IIRC and has only ever confused people. > > > cache_mem 500 MB > > connect_timeout 5 minutes > > dns_retransmit_interval 5 seconds > > dns_timeout 1 minutes > > persistent_request_timeout 2 minutes > > request_timeout 60 seconds > > maximum_object_size_in_memory 2000 KB > > maximum_object_size 800 MB > > > > I tried light pictures without more success > > > > 10.1.1.1 - - [07/Feb/2012:15:08:05 +0100] "GET > > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg > > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT > > 10.1.1.1 - - [07/Feb/2012:15:08:13 +0100] "GET > > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg > > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT > > 10.1.1.1 - - [07/Feb/2012:15:08:14 +0100] "GET > > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg > > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT > > 10.1.1.1 - - [07/Feb/2012:15:08:15 +0100] "GET > > http://images.nationalgeographic.com/wpf/media-live/photos/000/183/cache/transparent-squid-newbert_18395_600x450.jpg > > HTTP/1.1" 304 347 TCP_MISS:HIER_DIRECT > > > > The next day, I clear my web browser's cache and retry, there is > > TCP_HIT:NONE with only 3.0 (although there are many HIT in > > access.log in 3.1 and 3.2). If this is not a bug then how to > > explain such behavior ? > > The status is 304. Those responses do not have any body attached, so > there is nothing for Squid to collect and cache as it passes through. > > The 3.0 trace shows a 200 followed by IMS revalidations from the > client > which get relayed through to the server. > > For the others it looks a bit weird, but is possible under some > conditions. Without the sequence of full headers its impossible to > say > what *should* have or is happening in the other cases. > > For testing try using squidclient in a shell script to make a series > of > controlled calls. That way you can have a series of actions and know > in > advance what the Squid behaviour is supposed to be at each point of > the > test. Comparing what happens and what gets logged against the > expected > results. > If you have a trace of real traffic headers you can tune the > scripted > calls around what those do and compare the versions under identical > conditions. > > Amos > Thanks about urlpath_regex you are right it's ugly ... The problem persist with or without urlpath_regex, but I think now that I have a kind of cache corrupt because all seems good with another cache. I will format and retry
