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