[squid-users] URL filtering technical

Amos Jeffries squid3 at treenet.co.nz
Thu Dec 22 09:36:34 UTC 2022


On 17/12/2022 10:06 am, Lucas Vicente Pereira wrote:
>
> Good Evening, Community
>
> When thinking about URL filtering (http and or https), Which one is 
> the best technique you recommend for integration with Squid 5.7?
>

We cannot answer that question. "best" is subjective and depends on your 
use-case.

Please define what exactly you mean by "URL filtering" - that term can 
mean a lot of things not actually about "URL", nor "filter"s.


> 1 - External_acl (e.g.:
>

  ** Access control

Squid API intended for access control using calculations difficult or 
not possible with Squid built-in ACL logic.

Complexity of the rules and helper implementation determines the impact 
on traffic.
Limited to meta data about a transaction.


> 2 - I-CAP Servers
>

** This is for Content Adaptation

This passes the whole message, all its payload etc *everything* goes out 
from Squid to the ICAP server, then comes back in and gets re-parsed. 
Even with protocol optimizations this can cause up to double the 
processing lag for traffic going through the proxy.

  * eCAP which you omitted is similar but without nearly as much 
overhead costs as ICAP.

Ideally these should only be used when the adaptor logic is doing things 
with the message content, or complex header manipulations.


> 3 - url_rewrite_program (eg:
>
> url_rewrite_program /sbin/webfilter - url_rewrite_children 16 m 4 
> startup=8 idle=2 concurrency= -l /var/squid/logs 4
>

** This is for reverse-proxy / CDN internal URL modification

This API is for changing the URL (only) provided by the client **before* 
it gets fetched by Squid.
It should only be used by reverse-proxy traffic for /path?query of URLs. 
Protocol scheme, hostname changes should be done by cache_peer options.
Please do not use for access control - use external_acl_type instead.


HTH
Amos



More information about the squid-users mailing list