[squid-users] 'cache' config option and rewrite

Amos Jeffries squid3 at treenet.co.nz
Tue Dec 16 12:41:15 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16/12/2014 11:01 p.m., James Harper wrote:
> I have a rewrite rule so that any request for a list of apt
> repositories (acl dstdomain) are rewritten to instead go to my
> apt-cacher server, and then a "cache deny" rule to make sure squid
> doesn't cache files from these repositories. This seemed to be
> working fine but my latest attempt at a debian install kept failing
> because the gpg signature didn't match. It turns that that squid
> was actually caching these requests, which is the opposite of what
> I wanted as it meant that the sig and the file got out of sync (I
> guess apt-cacher doesn't return a proper indication of what is
> allowed to be cached and what isn't... so the sig was cached but
> the file wasn't, or something like that)
> 
> It turns out that "cache deny <dstdomain acl>" is processed after
> the rewrite, and against the rewritten url, so I needed to also
> exclude requests for my server running apt-cacher.
> 
> So for example:
> 
> acl apt_repo dstdomain ftp.au.debian.org acl apt_cacher browser
> apt-cacher # apt-cacher itself
> 
> cache deny apt_repo cache deny apt_cacher cache allow all
> 
> but I needed to add:
> 
> acl apt_repo dstdomain my.apt.cacher.server
> 
> This is kind of obvious in retrospect, but is it described anywhere
> which rules apply against the url before it is rewritten and which
> are applied to the rewritten url?
> 

URL re-write is a type of request adaptation.

The operational sequence of HTTP request processing is roughly:
 * parse + header interpretation
 * network traffic security/policy checks (http_access etc)
 * request adaptation (ICAP, eCAP, URL-rewrite/redirect)
 * security policy checks on adapted content (adapted_http_access etc)
 * source type selection (Store-ID rewrite, cache/store_hit directive)
 * client connection QoS setup
 * source-type specific file/worker/server setup
 * fetching the response

I'm not sure if we have it documented anywhere outside the code.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUkChqAAoJELJo5wb/XPRjJVoIAKyyiJY4koPWKXwQy7FBpcCR
Ts0K/glXs2dRDtElp5ijZo7qoxyKPHoE8/H5gJ97f6wb76syctKZNsjYbPjTStNo
G9qSN9prjo18MvYRZupmz6LTGeE+jKAeAcpoNiqprIAsR3H2uQpTAd0lXYIVGZly
EZ8v//IntiGGfEMFP6VP26AD6eG3uTXwUDEa0msv/PcuXTq0uH2monaMQU/aLzhr
rmxAPmLe/x6z0OqY6by/LCk4qFLfFe9lfA3MG2RnJh/ZAy/b6FeApGMQpAX+XfmK
it1U9uZIQUsxKpd6zKP6Ekk7T/j4AD1ImDwK0K03vfj9uKA+Svp/XSlhc9FEam8=
=XGfH
-----END PGP SIGNATURE-----


More information about the squid-users mailing list