On 22/10/22 01:50, Andy Armstrong wrote:
Hi Amos, All,
I continue to struggle with only receiving TCP_MISS when using
squid-cache. I have now implemented a server which is responding to HTTP
GETs. I have checked the endpoint with redbot.org and it states that :
1/The response allows all caches to store it
2/The response is fresh until 7 days from now
The reason may still be served by a cache once it becomes stale.
Therefore I believe the server side of this is now valid as a test for
squid cache.
Excellent.
My client, is routing calls to squidcache, and when it arrives there, I
see the following log entry:
1666355825.841106 10.1.1.70 TCP_MISS/200 60646 GET
http://192.168.20.1:3004/largeapp/largeapp/007005/bongo? -
HIER_DIRECT/192.168.20.1 application/json
The URL contains a query-string section. That is elided by default for
security (in case credentials or other sensitive info is in there).
To more accurately test this you should add this to your squid.conf:
strip_query_terms off
That will log the full query-string for accurate URL checking in
access.log. You can remove it for the production system later if you want.
If the resulting access.log shows any difference (one single byte is
enough) between the URLs they are different objects as far as the cache
can tell.
Are you using the Vary feature of HTTP at all? If so the exact bytes in
the named client headers matter (both case-sensitive and order-sensitive).
Infact every single client call I make results in this TCP_MISS.
I therefore think this may be to do with my squid.conf.
There does not appear to be anything wrong with your squid.conf.
I suspect some misunderstanding of the HTTP semantics.
...
refresh_pattern -i http:\/\/192.168.20.1:3001\/.* 10080 100% 43200
override-lastmod
refresh_pattern -i http:\/\/192.168.20.1:3004\/.* 10080 100% 43200
override-lastmod
The redbot.org results indicate that the object is cacheable according
to the server headers so you should not need these. I do not think they
are being harmful, but please remove for now to simplify the
troubleshooting.
Please do the following:
* add this to squid.conf to see the actual traffic flow in cache.log:
debug_options ALL,1 11,2
* make two (2) client requests for the same object. Waiting until the
server responses have both arrived.
* check access.log to verify the full URL is indeed identical.
We will need to see the HTTP traffic sequence you should be able to find
in cache.log. The log entries are multi-line and start with the
following tags, appearing in this order:
"HTTP Client REQUEST"
"HTTP Server REQUEST"
"HTTP Server RESPONSE"
"HTTP Client RESPONSE"
Please post the line(s) with that tag and the block of headers that
follow it.
If any other log lines appear interesting or suspicious, it would be
helpful to see those too and where exactly in the sequence they appear.
HTH
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
