210741 - PAC: serious performance loss when using isResolvable with IDN

Status: VERIFIED WORKSFORME

(Core :: Networking, defect)

Description

[Yoshiro, YONEYA]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

If users who using automatic proxy configuration (proxy.pac) entered an IDN,
proxy.pac looked up IDN in IDN (non-ACE) first and wait until DNS fail, then
looked up in ACE.  This is very serious performance loss.  AFAIK, this behaviour
was not observed before Mozilla-1.4b.

Reproducible: Always

Steps to Reproduce:
1. set automatic proxy configuration URL
2. access to IDN
3.

Actual Results:  
access to IDN site becomes very slow

Expected Results:  
The same access speed as ASCII domain name

Comment 1

[Katsuhiko Momoi]

I am going to confirm this bug based on Yoneya-san's report.
This does not look good. We should try to fix this as soon as 
possible. 
A Japanese Bugzilla entry for this bug is here:

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3244

Apparently if the performance degradation is very serious. If images
are included on the page, it seems to be even worse. 

Darin, does this ring a bell?

Comment 2

[Darin Fisher]

can someone please attach a sample PAC file that demonstrates the problem?  thx!

Comment 3

[Yoshiro, YONEYA]

Would you please try following proxy.pac?

function FindProxyForURL(url, host)
{
        if (!isResolvable(host)){
                proxystr = "DIRECT";
                return proxystr;
        }
        var proxystr = "PROXY aaa.bbb.ccc.ddd:8080";
        return proxystr;
}

Comment 4

[Phil Hannent]

Here is my proxy.pac

function FindProxyForURL(url, host)
{
    if (isPlainHostName(host) ||
        dnsDomainIs(host, ".elmstone.com") ||
        isInNet(host, "10.0.0.0", "255.255.255.0")) 
			{
	        return "DIRECT;";
			}
    else {
		
            if (url.substring(0, 5) == "http:") {

                return "PROXY proxy:9877; DIRECT";
            }
            else if (url.substring(0, 4) == "ftp:") {

                return "PROXY proxy:9877; DIRECT";
            }
            else if (url.substring(0, 7) == "gopher:") {

                return "PROXY proxy:9877; DIRECT";
            }
            else if (url.substring(0, 6) == "https:" ||
                     url.substring(0, 6) == "snews:") {

                return "DIRECT";
            }
            else {

                return "DIRECT";
            }
	}       
}

Comment 5

[Christophe Saout]

My whole browser hangs here while the automatic proxy script does a DNS lookup,
thread 1 is waiting in pthread_cond_wait. This is extremely ugly. It's okay to
wait but should not make the whole browser unusable.

Any progress on this?

Comment 6

[Darin Fisher]

fixing this properly requires moving execution of the PAC file to a background
thread, and we also need to make gecko wait asychronously for results from
FindProxyForURL.  that is a major architectural challenge for gecko that i do
not see getting fixed anytime soon... sadly :(

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

maybe "PAC" should just be a special proxy type for nsIProxyInfo, and the
resolving should happen upon asyncOpen or something, which would allow gecko to
continue necko as before.

Comment 8

[Darin Fisher]

(In reply to comment #7)
> maybe "PAC" should just be a special proxy type for nsIProxyInfo, and the
> resolving should happen upon asyncOpen or something, which would allow gecko to
> continue necko as before.

Right, we'd need to do that... BUT, here's the kicker... prior to calling
AsyncOpen, consumers like to QI to different interfaces to setup parameters. 
What type of channel should be created prior to knowing the proxy type?  In the
case of http:// and https:// it is pretty straightforward... we can just create
a HTTP channel, but what do we do in the ftp:// or gopher:// cases?  Do we
create a HTTP channel or do we create a FTP/GOPHER channel?  If we create the
FTP/GOPHER channel, then once the PAC file is queried, we might need to scrap
the FTP/GOPHER channel and restart.  One solution would be to treat it like a
redirect.  I've already wanted to generalize the nsIHttpEventSink::OnRedirect
event to something much more generic (nsIChannelEventSink::OnRedirect) that any
channel type could generate.  That would perhaps solve the problem, but it means
adding more code to any protocol that might potentially be proxied over HTTP. 
Another possibility is to create a dummy channel type that exists only to
redirect itself to a real protocol handler once the proxy type is discovered. 
We'd use this in all cases except http:// and https://, assuming the
nsIProtocolHandler for the URI set the ALLOW_PROXY_HTTP flag.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

this is not a IDN problem... moving to networking. this may be a duplicate.

Comment 10

[Darin Fisher]

In Mozilla 1.7, attempts by PAC to resolve IDN results in the ACE name being
resolved.  So, whatever problem existed in Moz 1.4 should be a thing of the past.

Marking WORKSFORME.

The fact that isResolvable and other DNS PAC functions blocks the browser UI is
covered by bug 235853.

Comment 11

[benc]

V, per Darin.