On 27/10/10 22:24, Marc Muehlfeld wrote:
One more information: I enabled debugging and got the following
information:
2010/10/27 11:22:36| The request CONNECT www.facebook.com:443 is
ALLOWED, because it matched 'MyNetworkMR_Clt'
But why it matches 'MyNetworkMR_Clt' and not rule 'blocked_urls'?
A mail I replied with earlier today has disappeared somewhere. I've sent
a new one with some things you can do to fix this problem and make your
squid work much better in future.
Please read my other long email before doing anything else.
As to your new "why" question. The answer is given by the log details.
(*** emphasis by me):
"
The request CONNECT *www.facebook.com:443* is ALLOWED
"
What got logged just there is the entire *exact* URL received by Squid.
And no, it does not look like what you seem to think of as URLs. It's a
CONNECT tunnel destination spec.
The Pattern you are using checks:
[^\/]\.facebook\.com\/
** trailing "/". path details are required. won't match.
[^\/]\.facebook\.com$
** requires the URL end with ".com" exact string. wont match.
^.*://facebook\.com)+
** requires "://" protocol details. wont match.
What you need to use instead is this:
acl facebook dstdomain .facebook.com
http_access deny facebook
Am 26.10.2010 14:12, schrieb Marc Muehlfeld:
Hello,
I have blocked some URLs through an url_regex acl, which works, if the
URL
contains any protocol execept https.
The "blocked_urls.lst" file contains lines like:
([^\/]\.facebook\.com\/|[^\/]\.facebook\.com$|^.*://facebook\.com)+
I've tested the regex using an online regex tester:
"http://www.facebook.com";
and "https://www.facebook.com"; both match. But the https address can be
reached, so I think, there must be a problem in my configuration (see
below).
I use 2.6.STABLE21 on CentOS 5.
Regards,
Marc
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.8
Beta testers wanted for 3.2.0.2
