Amos Jeffries wrote:
On Wed, 27 May 2009 17:16:41 +0200, "Boniforti Flavio" <flavio@xxxxxxxxxxx>
wrote:
In that case the config you posted is all correct. You have a
global allow for localnet before domini_bloccati is ever
tested so it can't even be a bad domain entry in there.
It must be something else doing the denial.
Thanks for double-replying, I looked at the access.log file and I see
only this:
1243437102.390 2 172.16.16.37 TCP_MISS/503 2458 GET http://teo/ -
DIRECT/teo text/html
1243437102.494 1 172.16.16.37 TCP_MISS/503 2459 GET
http://teo/favicon.ico - DIRECT/teo text/html
1243437105.496 1 172.16.16.37 TCP_MISS/503 2491 GET
http://teo/favicon.ico - DIRECT/teo text/html
It's clear to me that I'm getting TCP_MISS because in my network nor
elsewhere there is any "teo" host like the above. What makes me wonder
is *why* when I unset the proxy and I type "teo" in the address bar
(Firefox), I get:
http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1
&q=teo
It's a browser feature to use the address bar as a search box if there is
no resolvable URL.
Sorry, I'll clarify that a bit now that I have time.
The browsers try to search for the non-URL if they can't resolve it.
However when a proxy is present (any proxy, not just Squid) they dont do
any of the resolving, merely pass the URL to the proxy and wait for
results.
Squid by design does not do this search behavior so you end up with 'bad
URL' messages if you try to do it that way.
There is a workaround if you are using a proxy.pac file to configure the
browsers. The code in the file can do a isResolvable test (not sure of
the exact function call) and say DIRECT, which will get the browser
doing its normal behavior for non-resolvable domains. This will double
the DNS load though, so its not always a good thing.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE6 or 3.0.STABLE15
Current Beta Squid 3.1.0.8 or 3.0.STABLE16-RC1
