Build is from the morning of May 24, 2001. Now that PAC doesn't crash on startup and I turn my PAC back on any time that I visit a site that falls through to DIRECT the browser responds that the connection was refused. If I make my settings "Direct connection to the internet" I can connect anywhere.

Add darin and edburns since they get dragged into PAC problems sometimes.

Adding drapeau.

->serge

please enclose pac.

FWIW you should never return null from this function. The worst case should return DIRECT. But I understand this is only a testcase... :)

well, according to http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html >If the string is null, no proxies should be used. Is this deprecated in mozilla?

Ha! I had bet bbaetz that this indeed was the function that was being used. I don't think anyone had time to test this case (until now). when the result is "DIRECT", that does work for you, right? Please try this PAC file: http://frame.packetgram.com:443/direct Also, if anyone has time, please look at the PAC function test (draft) I have written at: http://www.packetgram.com/pktg/proxy/pactest.html As for a default behavior to handle incorrect returned values, I think we are going to support a DIRECT connection, its just that nobody had gotten to that level of feature testing yet. I sure hope we don't plan on erroring (because we already have lots of error conditions that need help).

Good point Serge!... I guess I was thinking from the impl perspective. I won't be surprised if we have a bug with returning NULL.

Uhh, my proxy file always returns DIRECT and I still get the connection refused problem: function FindProxyForURL(url, host) { if (host == "internalfoo.redhat.com") return "PROXY localhost:7003; DIRECT"; else return "DIRECT"; }

Benjamin Chuang on 2001-05-25 01:4 wrote: >when the result is "DIRECT", that does work for you, right? No, it does not work for file:///path_to_your_pac_file. http:// protocol throws an exception, check out java console for release build: * Call to xpconnect wrapped JSObject produced this error: * [Exception... "'[JavaScript Error: "LocalFindProxyForURL is not a function" ... which looks like a security issue in evalInSandbox(), and we are using no proxy at all:(

It seems to fixe both file:/// & http:// protocols. Gagan, could you please take a look on the patch? Thanks

serge: why is it necessary to set nsSocketTransport::mProxyTransparent to TRUE?

for proxy==direct we have to use mHostName not mProxyHost in: http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSocketTransport.cpp#6 16 616 rv = pDNSService->Lookup((mProxyHost && !mProxyTransparent) ? mProxyHost : mHostName, 617 this, 618 nsnull, 619 getter_AddRefs(mDNSRequest)); --- http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSocketTransport.cpp#8 83 882 nsXPIDLCString result; 883 const char *host = (mProxyHost && !mProxyTransparent) ? mProxyHost : mHostName; 884 rv = pDNSService->Resolve(host, getter_Copies(result)); 885 if (NS_FAILED(rv)) return rv; --------- the same for port: http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSocketTransport.cpp#6 02 602 mNetAddress.ipv6.port = PR_htons(((mProxyPort != -1 && !mProxyTransparent) ? mProxyPort : mPort)); ---- http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSocketTransport.cpp#9 03 902 mNetAddress.ipv6.port 903 = PR_htons(((mProxyPort != -1 && !mProxyTransparent) ? mProxyPort : mPort));

so for proxy==DIRECT, the ProtocolProxyService should return proxyHost = nsnull proxyPort = -1 proxyType = nsnull the rest of the code need not be changed IMO

let me clarify: the rest of necko need not be aware of the proxy DIRECT case.

that's a good point, all concerns are resolved in the second patch.

sr=darin once you fix the indentation.

*** This bug has been marked as a duplicate of 79371 ***

REOPENING: Duplicated to original that is a different problem.

Are you saying the patch I checked in for 79371 does not fix this problem? Do you have a test case?

I got disconnected before I could finish the status change.

+verifyme. If someone volunteers to verify on Linux, I'll give temporary access to my proxy server for this bug, if you do the basic PAC functional test: http://www.packetgram.com/pktg/proxy/pac/pactest.html

mass remove verifyme requests greater than 4 months old