[squid-users] TCP_MISS_ABORTED/502

[Amos Jeffries]

On 12/07/24 03:37, Ben Toms wrote:
> Hi folks,
> 
> We’re looking to leverage squid-cache as an accelerator, but for large 
> content. For example, a local cache of macOS installers so that the 
> internet line isn’t swamped when updating Photoshop etc across devices.
> 
> Below is an example of the conf I’ve been using (and have been going 
> backwards and forwards trying different things):
> 
> https_port 443 accel protocol=HTTPS tls-cert=/usr/local/squid/client.pem 
> tls-key=/usr/local/squid/client.key
> 
> cache_peer public.server.fqdn parent 443 0 no-query originserver 
> no-digest no-netdb-exchange tls login=PASSTHRU name=myAccel
> 

I suggest also adding the option to this cache_peer line:
    forceddomain=public.server.fqdn


> acl our_sites dstdomain local.server.fqdn
> 
> http_access allow our_sites
> 
> cache_peer_access myAccel allow our_sites
> 
> cache_peer_access myAccel deny all
> 
> refresh_pattern -i public.server.fqdn/.* 3600    80%     14400

Note: you do not need to put ".*" at either end of a regex. It is implicit.


> 
> cache_dir ufs /usr/local/squid/var/cache 100000 16 256
> 
> When I attempt to curl a file from local.server.fqdn, I can see that 
> there has been a request made to public.server.fqdn and that the 
> authentication has been passed through and all is well (it returns a 200 
> code and needs authentication),


That does not make sense. "needs authentication" in HTTP is a 4xx status 
code.

A response cannot be 200 "OK, successful complete" and "needs 
authentication" at the same time.


> but I’m seeing TCP_MISS_ABORTED/502 in 
> /var/log/squid/access.log as per the below:
> 
> 1720711470.297     84 192.168.0.156 TCP_MISS_ABORTED/502 3974 GET 
> https://local.server.fqdn/some/file/path 
> <https://local.server.fqdn/some/file/path> - 
> FIRSTUP_PARENT/public.ip.of.public.server text/html
> 
> Seems like the client to squid-cache HTTPS conection is fine, and 
> squid-cache can contact public.server.fqdn.. but nothing is cached.
> 

There is nothing in the above which indicates a problem caching.

There is a client doing unexpected abort - which may (or not) have 
side-effects on storage of the response. But still no problem exactly - 
clients can do what they want.


Cheers
Amos