[squid-users] TCP_MISS only

Andy Armstrong andy.armstrong at uk.ibm.com
Tue Sep 27 10:01:24 UTC 2022


Hi Alex,

That makes a lot of sense, I don’t know how I overlooked that – thank you. I also agree, logically caching a 201 response makes little sense, and it was just an example I had that was easy to try so I used that.

I just altered the HTTP Return code so it sent 200 instead of 201, and the result is sadly the same, I get many, many lines like this:


1664272638.443  10107 10.1.1.70 TCP_MISS/200 275 POST http://192.168.0.2:3001/InternalCommunicationServices/message/email - HIER_DIRECT/192.168.0.2 application/json

My suspicion is still that my refresh_pattern is wrong:

refresh_pattern -i http:\/\/129.168.0.2:3001\/.* 10080 100% 43200 override-lastmod

Kind regards,

Andy Armstrong
安迪 阿姆斯特朗
Principal Specialist for Z Technologies
EMEA Squad Leader for Hybrid Cloud
Worldwide Community Leader for Hybrid Cloud
Member of the CTO Office Server & Storage EMEA
Distinguished Technical Specialist – The Open Group
IBM Master Inventor

Mobile: +447500103874



From: squid-users <squid-users-bounces at lists.squid-cache.org> on behalf of Alex Rousskov <rousskov at measurement-factory.com>
Date: Monday, 26 September 2022 at 21:07
To: squid-users at lists.squid-cache.org <squid-users at lists.squid-cache.org>
Subject: [EXTERNAL] Re: [squid-users] TCP_MISS only
On 9/26/22 15:27, Andy Armstrong wrote:

> My aim – is that for any HTTP response from 192.168.0.2:3001 is
> cached and served from the cache.

> 1664219486.83610098 10.1.1.70 TCP_MISS/201 492 POST
> http://192.168.0.2:3001/InternalCommunicationServices/message/email   -
> HIER_DIRECT/192.168.0.2 application/json

Squid does not cache responses with HTTP status code 201 (Created). Per
HTTP protocol, such responses are not cachable "by default" and Squid is
not smart enough to check whether a particular 201 response has headers
that would allow Squid to overwrite that default. The specific response
in question probably does not have those headers, but I am mentioning
them here for completeness sake.

Furthermore, a "Created" response to a POST request probably does not
contain anything you would want to cache -- things will probably break
if that "create something" POST request is satisfied from the cache the
next time around. You may need to study the HTTP server in question and
adjust your goals from "cache any 192.168.0.2:3001 response" to
something more nuanced, based on what that server does.


HTH,

Alex.




> My config is as follows:
>
> http_port 3128
>
> acl localnet src 10.0.0.0/8     # RFC1918 possible internal network
>
> acl localnet src 172.16.0.0/12  # RFC1918 possible internal network
>
> acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
>
> acl localnet src fc00::/7       # RFC 4193 local private network range
>
> acl localnet src fe80::/10      # RFC 4291 link-local (directly plugged)
> machines
>
> acl SSL_ports port 443
>
> acl Safe_ports port 80          # http
>
> acl Safe_ports port 21          # ftp
>
> acl Safe_ports port 443         # https
>
> acl Safe_ports port 70          # gopher
>
> acl Safe_ports port 210         # wais
>
> acl Safe_ports port 280         # http-mgmt
>
> acl Safe_ports port 488         # gss-http
>
> acl Safe_ports port 591         # filemaker
>
> acl Safe_ports port 777         # multiling http
>
> acl Safe_ports port 1025-65535  # unregistered ports
>
> acl CONNECT method CONNECT
>
> http_access deny !Safe_ports
>
> http_access deny CONNECT !SSL_ports
>
> http_access allow localhost manager
>
> http_access deny manager
>
> http_access allow localnet
>
> http_access allow localhost
>
> http_access deny all
>
> coredump_dir /squid/var/cache/squid
>
> cache_dir ufs /var/spool/squid 1024 16 256
>
> refresh_pattern -i http://192.168.0.2:3001%5C/.*   10080 100% 43200
> override-lastmod
>
> refresh_pattern ^ftp:                      1440      20%        10080
>
> refresh_pattern ^gopher:             1440      0%          1440
>
> refresh_pattern -i (/cgi-bin/|\?) 0             0%          0
>
> refresh_pattern .                              0              20%
> 4320
>
> The problem I am finding is that each time my client makes a call via
> the proxy, I see this in the logs:
>
> 1664219486.83610098 10.1.1.70 TCP_MISS/201 492 POST
> http://192.168.0.2:3001/InternalCommunicationServices/message/email   -
> HIER_DIRECT/192.168.0.2 application/json
>
> I see the ‘TCP_MISS’,  the client receives the response from the remote
> server, but on subsequent calls, it continues to trigger TCP_MISS and I
> never manage to cache the response.
>
> Please help me understand what I am missing from the configuration for
> my intended use case.
>
> Kind regards,
>
> Andy Armstrong
>
> 安迪阿姆斯特朗
>
> Principal Specialist for Z Technologies
>
> EMEA Squad Leader for Hybrid Cloud
>
> Worldwide Community Leader for Hybrid Cloud
>
> Member of the CTO Office Server & Storage EMEA
>
> Distinguished Technical Specialist – The Open Group
>
> IBM Master Inventor
>
>
> Mobile: +447500103874
>
> Unless otherwise stated above:
>
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20220927/91e5f3fd/attachment-0001.htm>


More information about the squid-users mailing list