On 2024-10-10 20:48, Jonathan Lee wrote:
miss means it stored items
Just to correct a misunderstanding: A cache miss does _not_ imply that
Squid stored the response.
Alex.
On Oct 10, 2024, at 15:27, Bryan Seitz <seitzbg@xxxxxxxxx> wrote:
I removed the header mods and changed the refresh pattern to:
refresh_pattern . 15 20% 1800
override-expire ignore-no-cache ignore-no-store ignore-private
And I always get TCP_MISS. Any other thoughts?
Thanks!
On Thu, Oct 10, 2024 at 12:35 PM Alex Rousskov
<rousskov@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>> wrote:
On 2024-10-09 15:40, Bryan Seitz wrote:
> SSL-Bump Woes
AFAICT, the problem you are trying to solve is not caused by SslBump.
> reply_header_access Cache-Control deny all
> reply_header_add Cache-Control "public, max-age=1800"
The above directives are applied to responses that Squid sends to
clients. These post-cache response modification directives have no
effect on Squid response caching decisions (which are done earlier,
pre-cache, while looking at the virgin or adapted response
received from
the origin server of cache_peer).
FWIW, this caveat is documented in reply_header_add description, but
documentation improvements are welcome:
> This option adds header fields to outgoing HTTP responses (i.e.,
response
> headers delivered by Squid to the client). This option has no
effect on
> cache hit detection. The equivalent adaptation vectoring point in
> ICAP terminology is post-cache RESPMOD.
To allow Squid to violate HTTP caching rules when deciding whether
to a
cache a response, see refresh_pattern options (e.g.,
"ignore-private").
http://www.squid-cache.org/Doc/config/refresh_pattern/
<http://www.squid-cache.org/Doc/config/refresh_pattern/>
HTH,
Alex.
> I have the following configuration:
>
> http_port 3128 ssl-bump generate-host-certificates=on
> tls-cert=/etc/squid/ssl/myCA.pem
> ssl_bump bump all
>
> # BMCs return Cache-Control: private
> reply_header_access Cache-Control deny all
> reply_header_add Cache-Control "public, max-age=1800"
>
> follow_x_forwarded_for allow all
> http_access allow all
> include /etc/squid/conf.d/*.conf
> host_verify_strict off
> tls_outgoing_options min-version=1.0
> flags=DONT_VERIFY_PEER,DONT_VERIFY_DOMAIN
> sslproxy_cert_error allow all
>
> sslcrtd_program /usr/lib/squid/security_file_certgen -s
> /var/spool/squid/ssl_db -M 4MB
> sslcrtd_children 5
>
> cache_mem 8192 MB
> cache_dir rock /cm/squid/squid 8192
>
> buffered_logs on
> access_log daemon:/var/log/squid/access.log logformat=squid
> logfile_daemon /usr/lib/squid/log_file_daemon
> cache_store_log daemon:/var/log/squid/store.log
> log_mime_hdrs on
> coredump_dir /var/spool/squid
> shutdown_lifetime 2 seconds
> max_filedesc 4096
> workers 4
>
>
> A curl will note the resource is stale (with new host), but I
never get
> a cache hit on subsequent retries:
>
> Store log:
>
> 1728502393.992 RELEASE -1 FFFFFFFF
02000000000000003A632F0003000000 200
> 1728502382 -1 -1 application/json 1182/1182 GET
>
https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics> <https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics>>
> 1728502395.674 RELEASE -1 FFFFFFFF
02000000000000003B632F0002000000 200
> 1728502384 -1 -1 application/json 1182/1182 GET
>
https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics> <https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.77/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics>>
> 1728502408.317 RELEASE 00 00056924
04000000000000003C632F0001000000 200
> 1728420588 -1 1728422388 application/json 1189/1189 GET
>
https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics> <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics>>
> 1728502408.318 RELEASE -1 FFFFFFFF
03000000000000003C632F0001000000 200
> 1728502404 -1 -1 application/json 1179/1179 GET
>
https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics> <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics>>
> 1728502417.161 RELEASE -1 FFFFFFFF
05000000000000003C632F0001000000 200
> 1728502413 -1 -1 application/json 1179/1179 GET
>
https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics> <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics <https://10.170.31.81/redfish/v1/Oem/Supermicro/HGX_H100/Systems/HGX_Baseboard_0/Processors/GPU_SXM_4/ProcessorMetrics>>
>
> Response headers:
>
> HTTP/1.1 200 Connection established
>
> HTTP/1.1 200 OK
> Link: <http://redfish.dmtf.org/schemas/v1/Z.v1_5_2.json
<http://redfish.dmtf.org/schemas/v1/Z.v1_5_2.json>
> <http://redfish.dmtf.org/schemas/v1/Z.v1_5_2.json
<http://redfish.dmtf.org/schemas/v1/Z.v1_5_2.json>>>; rel=describedby
> Allow: GET
> Content-Length: 1179
> Content-Type: application/json; charset=UTF-8
> Strict-Transport-Security: max-age=31536000; includeSubdomains
> X-XSS-Protection: 1; mode=block
> Content-Security-Policy: default-src 'self';connect-src 'self' ws:
> wss:;frame-src 'self';img-src 'self' data:;object-src
'self';font-src
> 'self' data:;script-src 'self' 'unsafe-inline'
'unsafe-eval';style-src
> 'self' 'unsafe-inline';worker-src 'self' blob:;
> X-Frame-Options: SAMEORIGIN
> X-Content-Type-Options: nosniff
> OData-Version: 4.0
> Date: Wed, 09 Oct 2024 19:35:50 GMT
> Cache-Status: squid;detail=mismatch
> Via: 1.1 squid (squid/6.10)
> Connection: keep-alive
> Cache-Control: public, max-age=1800
>
> If I use a cache peer with MITMPROXY, squid will cache the results
> however this is inefficient and slow.
>
> --
> Bryan Seitz
> seitzbg@xxxxxxxxx <mailto:seitzbg@xxxxxxxxx>
<mailto:seitzbg@xxxxxxxxx <mailto:seitzbg@xxxxxxxxx>>
>
> _______________________________________________
> squid-users mailing list
> squid-users@xxxxxxxxxxxxxxxxxxxxx
<mailto:squid-users@xxxxxxxxxxxxxxxxxxxxx>
> https://lists.squid-cache.org/listinfo/squid-users
<https://lists.squid-cache.org/listinfo/squid-users>
--
Bryan Seitz
seitzbg@xxxxxxxxx <mailto:seitzbg@xxxxxxxxx>
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
