On 9/12/19 11:02 AM, fansari wrote: > This is the first behaviour I don't want like this: In the future, please post all access.log records from the test case up to and including the first one you do not like (not just the first one you do not like). In caching, _history_ matters. > 1568300283.479 3896 xxx.xxx.0.239 TCP_MISS/200 6724533 GET > https://xxx/1.mp4 - HIER_DIRECT/xxx.xxx.24.241 video/mp4 > The content of the mp4 file has not changed. Nevertheless after clearing the > browser cache the content produces a MISS instead of a HIT. Understood. What does your "squid -v" say (I am looking for ./configure options). If you see --enable-delay-pools, then do not trust the TCP_MISS status code. It can be a cache hit in that case. I am not saying it _was_ a hit. Just cautioning from trusting TCP_MISS too much when running with --enable-delay-pools. Please set debug_options to ALL,2, repeat the test from scratch, and share the request headers received by Squid, the request headers sent by Squid, the response headers received by Squid, and the response headers sent by Squid. You will find all these headers in cache.log. You can just share a (compressed) cache.log if you prefer. Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
