Re: [squid-users] Strange browser behavior / issue with proxy autoconfiguration file

Am 10.03.2010 20:30, schrieb Henrik Nordström:
>> What happens is that as soon as an URL with a non-existent DNS name is
>> entered, the browser locks up for almost 90 seconds before it displays
>> Squid's DNS error message (ERR_DNS_FAIL).
>>
> Sounds like a DNS issue. isInNet requires the client to perform a DNS
> lookup of the host name.
>
It was indeed an issue with the isInNet part - calling it three times in
a row causes three DNS lookups, thus thrice the delay.

> [...]
>
> isPlainHostname should work.. assuming the problem is DNS.
>
isPlainHostName alone probably won't help, unless I'm mistaken... as it
will not trigger on IPs, only on hostnames without dots.
So what I came up with is a multi-step process, which seems to work even
faster than a single DNS query:

isPlainHostname - return DIRECT

  (!(shExpMatch(host,"*[a-z]*"))) - no letters in host string
         in that case, it must be an IP, so performing an isInNet works
without DNS
             (isInNet(host, "192.168.0.0", "255.255.0.0") ||
             isInNet(host, "172.16.0.0", "255.240.0.0") ||
             isInNet(host, "10.0.0.0", "255.0.0.0"))
         if it's an internal IP, return DIRECT, if it's an external one,
return PROXY
anything else, return PROXY

> Does it work properly if you just return the proxy address? (as a test)
>
Yes, it does.

[...]
> Do the local DNS used by the client promptly reject non-local names?
Yes it does, that's why the browser's behavior surprised me.
Entering the Proxy data directly instead of using the pac file makes the
browser return the error page immediately, so the DNS server isn't the
culprit.

Also, granting the client DNS (same DNS server, only now supplying
external DNS data as well) and direct web access via the router/firewall
makes the browser respond immediately, too.

I also tried to reproduce the issue with wget, not using a pac file (not
sure if wget would be able to parse one, anyway) but once with
http_proxy=... set and once with --no-proxy.
The response via the proxy was faster and returned a 504 Gateway Timeout
or something like that.
Still, I could have lived with the time needed by both wget and the
browser when in direct mode or when using a fixed proxy, had I not found
the solution above.
Locking up the entire browser for the time it takes to do three DNS
queries is simply not acceptable, though.
I think it's safe to say that neither the DNS server involved, nor squid
are at fault here - there seems to be some buggy code in the browser.

Kind Regards,
Stefan
Received on Wed Mar 10 2010 - 20:18:56 MST