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
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
