Version: unknown (using KDE 3.1.93 (CVS >= 20031111), compiled sources) Compiler: gcc version 3.3.1 (SuSE Linux) OS: Linux (i686) release 2.4.21-99-athlon Latest js changes (I think <= 1 week) introduced a regression in konquerors automatic proxy detection (proxy script) functionality. Sorry for not being able to give more details, but it seems, that js does not correctly execute the attached script correctly any longer.
Created attachment 3405 [details] JS-Script used is at work by my employer
really needs to be fixed before release.
Hello, It works fine for me with today's cvs. At least when manually specifying the script file in the proxy config dialog. You can then easily test and see if kded module that handles automatic proxy configuration gives back the correct response by issuing the following command: dcop kded proxyscout proxyForURL <URL> where <URL> the url you want to test, e.g. http://www.kde.org
so far all you have is a "it seems"
Hi Dawit, Thanks for the hint. I'll try tomorrow's CVS snapshot on Monday in the office and update this bug-report acordingly. Helge
I tried again with Saturday's CVS HEAD with a scratch build. Same result: automatic proxy _IS_ definitively broken. Dawit: Are you maybe running some "kio_http_experimental" tagged stuff ? Maybe relevant parts of stracing "dcop kded proxyscout proxyForURL http://www.kde.org" gives: socket(PF_UNIX, SOCK_STREAM, 0) = 5 uname({sys="Linux", node="ls3530", ...}) = 0 connect(5, {sa_family=AF_UNIX, path="/tmp/.ICE-unix/dcop4092-1070873797"}, 37) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 write(5, "\0\1\0\0\0\0\0\0", 8) = 8 read(5, "\0\1\0\0\0\0\0\0", 8) = 8 access("/home/deller/.ICEauthority", R_OK) = 0 open("/home/deller/.ICEauthority", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0600, st_size=1699, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40725000 read(6, "\0\3ICE\0\0\0/local/ls3530:/tmp/.ICE-"..., 4096) = 1699 read(6, "", 4096) = 0 close(6) = 0 munmap(0x40725000, 4096) = 0 write(5, "\0\2\1\1\6\0\0\0\0\0\0\0\0\0\0\0\3\0MIT\0\0\0\3\0001.0"..., 56) = 56 read(5, "\0\3\0\0\1\0\0\0", 8) = 8 read(5, "\0\0\0\0\0\0\0\0", 8) = 8 access("/home/deller/.ICEauthority", R_OK) = 0 open("/home/deller/.ICEauthority", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0600, st_size=1699, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40725000 read(6, "\0\3ICE\0\0\0/local/ls3530:/tmp/.ICE-"..., 4096) = 1699 close(6) = 0 munmap(0x40725000, 4096) = 0 write(5, "\0\4\1\1\3\0\0\0\20\0\0\0\0\0\0\0\352\250\236\261\321\224"..., 32) = 32 read(5, "\0\6\0\0\2\0\0\0", 8) = 8 read(5, "\3\0MIT\0\0\0\3\0001.0\0\0\0", 16) = 16 access("/home/deller/.ICEauthority", R_OK) = 0 open("/home/deller/.ICEauthority", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0600, st_size=1699, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40725000 read(6, "\0\3ICE\0\0\0/local/ls3530:/tmp/.ICE-"..., 4096) = 1699 read(6, "", 4096) = 0 close(6) = 0 munmap(0x40725000, 4096) = 0 write(5, "\0\7\2\0\7\0\0\0\1\1\0\0\0\0\0\0\4\0DCOPgI\3\0KDE\26\305"..., 64) = 64 read(5, "\0\3\0\0\1\0\0\0", 8) = 8 read(5, "\0\0MIT\0\0\0", 8) = 8 access("/home/deller/.ICEauthority", R_OK) = 0 open("/home/deller/.ICEauthority", O_RDONLY) = 6 fstat64(6, {st_mode=S_IFREG|0600, st_size=1699, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40725000 read(6, "\0\3ICE\0\0\0/local/ls3530:/tmp/.ICE-"..., 4096) = 1699 close(6) = 0 munmap(0x40725000, 4096) = 0 write(5, "\0\4\2\0\3\0\0\0\20\0\0\0\0\0\0\0\352\250\236\261\321\224"..., 32) = 32 read(5, "\0\10\0\2\2\0\0\0", 8) = 8 read(5, "\3\0KDE\0\0\0\3\0002.0\0\0\0", 16) = 16 getsockopt(5, SOL_SOCKET, SO_PEERCRED, "\374\17\0\0\364\1\0\0\364\1\0\0", [12]) = 0 getuid32() = 500 getpid() = 9184 write(5, "\2\2\2\0H\0\0\0\0\0\0\0", 12) = 12 write(5, "\0\0\0\0\0\0\0\vDCOPServer\0\0\0\0\1\0\0\0\0\25regi"..., 53) = 53 write(5, "\0\0\0\17anonymous-9184\0", 19) = 19 read(5, "\2\3\0\0027\0\0\0", 8) = 8 read(5, "~\0\0\0", 4) = 4 read(5, "\0\0\0\vDCOPServer\0\0\0\0\0\0\0\0\tQCString\0"..., 55) = 55 write(5, "\2\2\2\0?\0\0\0~\0\0\0", 12) = 12 write(5, "\0\0\0\17anonymous-9184\0\0\0\0\5kded\0\0\0\0\v"..., 63) = 63 read(5, "\2\3\0\2\314\0\0\0", 8) = 8 read(5, "~\0\0\0", 4) = 4 read(5, "\0\0\0\5kded\0\0\0\0\17anonymous-9184\0\0\0\0\r"..., 204) = 204 write(5, "\2\2\2\0\206\0\0\0~\0\0\0", 12) = 12 write(5, "\0\0\0\17anonymous-9184\0\0\0\0\5kded\0\0\0\0\v"..., 69) = 69 write(5, "\0\0\0\10\0h\0t\0t\0p\377\377\377\377\377\377\377\377\0"..., 65) = 65 read(5, "\2\5\0\2 \0\0\0", 8) = 8 read(5, "~\0\0\0", 4) = 4 read(5, "\0\0\0\5kded\0\0\0\0\17anonymous-9184\0\0\0\0\16", 32) = 32 read(5, < it just hangs here ...> it would be nice, if someone else could confirm this bug.
Hello, The kio_http_experimental stuff has nothing to do with the quick test I mentioned above. The automatic proxy config handler is now its own kded module in KDE 3.2. It was not in 3.1. So if you are saying the result of executing the command above results in it getting stuck, then there is a problem with your proxy kded module. Please check whether or not this module is Running in the control center: K->Settings->Control Center->KDE Components->Service Manager and look for a "Load-On Demand Service" called Proxy Scout. What is its status ? Another thing is do you still have 3.1 installed ? Regards, Dawit A.
*** Bug 69631 has been marked as a duplicate of this bug. ***
Hi Dawit, as requested, I checked the following things: - The "Load-On Demand Service" called Proxy Scout is running (it starts automatically if I change to automatic proxy) - No, I don't have any other KDE version installed on my machine beside KDE 3.2beta2 (as said before - it worked until around 4 weeks ago). Any other ideas ? Thanks, Helge
*** Bug 70133 has been marked as a duplicate of this bug. ***
Please try the following. First make sure you have selected "Automatically detect proxy Configuration" in the proxy config dialog... As root in a terminal window (xterm, konsole) type: tcpdump -n src <your-machine-ip> udp In another terminal window issue the following 2 commands one at a time: dcop kded proxyscout reset dcop kded proxyscout proxyForURL <url> What output do you see in the tcpdump window ? What is the result of the second dcop command ? If the last dcop request seems to get stuck, try changing the server response timeout to something more saner like 45 sec instead of the default 600. Repeat the whole process and wait about a minute. Does it return a result ? Perhaps "DIRECT" ? Please do not forget to do the tcpdump as well. That is the only way to tell whether or not the proxy handler did actually send off a request...
Hi Dawit, I did some tests. First of all my machine has this network card setup (one is by DHCP, the other one is a fixed IP - I need on my laptop inside the company): ls3530:~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:00:E2:6E:CD:65 inet addr:10.18.201.30 Bcast:10.255.255.255 Mask:255.255.252.0 inet6 addr: fe80::200:e2ff:fe6e:cd65/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:271043 errors:0 dropped:0 overruns:0 frame:0 TX packets:180433 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:71602830 (68.2 Mb) TX bytes:20666012 (19.7 Mb) Interrupt:11 Base address:0xf000 eth0:0 Link encap:Ethernet HWaddr 00:00:E2:6E:CD:65 inet addr:10.18.202.55 Bcast:10.255.255.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:11 Base address:0xf000 With this in mind I started tcpdump (are the parameters correct?): ls3530:~ # tcpdump -n host 10.18.201.30 or host 10.18.202.55 tcpdump: listening on eth0 19:42:41.482738 10.18.201.30.877 > 10.18.200.30.1023: udp 56 (DF) 19:42:41.483230 10.18.200.30.1023 > 10.18.201.30.877: udp 28 (DF) 19:42:47.474772 arp who-has 10.18.200.30 tell 10.18.201.30 19:42:47.475017 arp reply 10.18.200.30 is-at 8:0:20:9e:cd:f5 The then I did: deller@ls3530:/mnt/hda5/home/deller> dcop kded proxyscout reset deller@ls3530:/mnt/hda5/home/deller> dcop kded proxyscout proxyForURL http://www.kde.org The above tcpdump output was the only thing I got after starting the "proxyForURL" dcop command. So IMHO it seems, that the proxy handler didn't send off a request. BTW: How do I change the server response timeout ?
Issuing "kcmshell netpref" in minicli or the command line is the quickest way to get the network timeout config dialog. Hmm.. interesting. You have a multi-homed machine. I was only testing on a machine with a single nic. To which IP address is your machine's hostname tied ? Also did you check to make sure your proxy config was set to "Automatically detect..." and port 68 was NOT being used a client DHCP daemon ? The expected result from the tcpdump is as follows: bash-2.05b# tcpdump -n src 192.168.10.1 and udp tcpdump: listening on eth0 00:00:58.180960 192.168.10.1.68 > 255.255.255.255.67: htype-#0 hlen:0 xid:0x2d254074 C:192.168.10.1 file ""[|bootp] (DF) 00:01:03.239933 192.168.10.1.35735 > 192.168.10.10.53: 56158+ A? wpad.net.lan. (30) (DF) 00:01:03.310188 192.168.10.1.35735 > 192.168.10.10.53: 56159+ A? wpad.net.lan. (30) (DF) 00:01:03.327270 192.168.10.1.35735 > 192.168.10.10.53: 37549+ SOA? net.lan. (25) (DF) 00:01:03.447695 192.168.10.1.35735 > 192.168.10.10.53: 56160+ A? wpad.lan. (26) (DF) 00:01:03.471873 192.168.10.1.35735 > 192.168.10.10.53: 56161+ A? wpad.lan. (26) (DF) 00:01:03.494348 192.168.10.1.35735 > 192.168.10.10.53: 37550+ SOA? lan. (21) (DF) A DHCP request followed by a DNS query for the config information...
*** Bug 60885 has been marked as a duplicate of this bug. ***
I have the problem on my laptop with a single NIC. As I pointed out in bug 69631 do I see no traffic at all when autoconfiguring. But above you asked "To which IP address is your machine's hostname tied?" -- when I looked, I found out that `hostname -f` gives 'localhost' on my box. So it seems like my DHCP client doesn't set the host and domain name correctly. And as 'localhost' is no FQDN, the program can'f find a host named 'wpad' in that non-existant domain. q.e.d. :) At least do I guess that it's just some kind of mis-configuration, I'll try to find out this weekend.
That is exactly the problem. None of the Linux DHCP clients I know of, dhcpd and pump, modify the /etc/hosts file and as a result any client that obtains its IP address through DHCP will have a "misconfigured" hosts file. Below is an example of what the localhost entry in /etc/hosts should look like if you are only using DHCP. Do not do this if you have both static and dynamic based NICs. 127.0.0.1 foo.bar.com foo localhost instead of either one of the following below 127.0.0.1 localhost 127.0.0.1 localhost.localdomain localhost Regards, Dawit A.
But that's no real solution; WPAD auto detection means I want to autodetect the proxy on whichever network I'm currently. So if I am at home, I want it to look up wpad.msquadrat.de but at university it needs to point to wpad.fh-wedel.de. The good news is that with dhcpcd it's possible to execute a script whenever the information changes. I already use this in combination with ifplugd to rewrite /etc/resolv.conf, including the 'domain' statement. My /etc/hosts file contains only 127.0.0.1 localhost treehouse so I wonder why the resolver doesn't tack the domain to these names... But that's some libc weirdness and out of the scope of this bug. So it seems that these problems are actually misconfigurations and can't really be fixed in KDE. But the user can't know this, for him it just "doesn't work"; maybe a warning/info dialog (for after 3.2 of course) would be useful when you enable the auto detection? Hmmm... maybe it is possible to make the proxyscout a bit more intelligent. For one, I don't know what it already does; but even if I killed dhcpcd before I tried (and such released poirt 68), it didn't work. So, does the proxyscout only try to fetch the DHCP information for the WPAD config, or does it already fall back to retrieving the 'domain' entry, looking up wpad.domain (vs. wpad.gethostbyname())? Another way to make it more intelligent would be to iterate over all interfaces and try to resolve the FQDN for each assigned IP. Based on that info, other WPAD servers could be sought. That probably wouldn't always give the correct information, but it should be correct in most cases.
"these problems are actually misconfigurations and can't really be fixed in KDE"
Come on Coolo - you are not serious, arent't you ?!? This works with KDE 3.1.x, so why shouldn't it work in KDE 3.2 (CVS) too ?
This bug actually has two aspects: 1. The DHCP/auto-detection part. That's broken because of misconfiguration. 2. The KJS part. See the attachment 3600 [details] from bug 69631. It's a valid PAC file which works with IE and Mozilla. But even if you enter this PAC file manually in Konq, it doesn't work and the proxyscout always returns "DIRECT". So, at least for me, proxy-autoconfiguration is completely broken. I think this bug is at least "major". If there's anything I can do to help debugging the problem, please tell.
Created attachment 4077 [details] Testcase which shows that myIpAddress() is broken. Here's the real culprit: It seems like the call to myIpAddress() breaks the script. This script should always return "PROXY foo:0" but it returns "DIRECT". Uncomment the first line and it correctly returns "PROXY bar:0".
After looking at the source I finally found out that it's possible to enable notifications about errors via KNotify. Which gave me: The proxy configuration script returned an error: ReferenceError: Can't find variable: myIpAddress So it seems like myIpAddress [PAC-MIA] is simply not implemented. Still digging into this... [PAC-MIA]http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html#myIpAddress
Created attachment 4080 [details] Patch for the myIpAddress() problem. Doh. myIpAddress() didn't work because of a simple typo :) Could somebody please apply this patch?
great news! I checked KDE 3.1 and it's indeed that simply typo ;( will commit asap
Subject: kdelibs/kio/misc/kpac CVS commit by coolo: changed the name of the function back to what it was in KDE 3.1 CCMAIL: 69026-done@bugs.kde.org M +4 -4 script.cpp 1.8 --- kdelibs/kio/misc/kpac/script.cpp #1.7:1.8 @@ -199,7 +199,7 @@ namespace }; - // myIPAddress() + // myIpAddress() // @returns the local machine's IP address in dotted quad notation - struct MyIPAddress : public Function + struct MyIpAddress : public Function { virtual Value call( ExecState*, Object&, const List& args ) @@ -402,6 +402,6 @@ namespace global.put( exec, "dnsResolve", Object( new DNSResolve ) ); - global.put( exec, "myIPAddress", - Object( new MyIPAddress ) ); + global.put( exec, "myIpAddress", + Object( new MyIpAddress ) ); global.put( exec, "dnsDomainLevels", Object( new DNSDomainLevels ) );
The patch fixed only one aspect of this bug. Changed the summary accordingly and set to wish, reopened.
reopen, I said :)
I work with Helge and have been trying to track down this same issue. It's actually a freeze in kded when trying to execute a DCOP call that freezes. It's a syncronous process so Konq locks waiting for the call to return. If you kill kded then Konq unfreezes (then the call actually fails) and says that it can't connect to the host. The place that these are locking is at: #6 0x40181133 in KProtocolManager::proxyForURL(KURL const&) (url=@0x8147d28) at kprotocolmanager.cpp:249 Which is: DCOPRef( "kded", "proxyscout" ).call( "proxyForURL", url ).get( proxy ); If it's useful I can post the rest of the trace, but I think that's the most interesting part. It's of note that this all works fine if the the proxy configuration script is copied to the local disk so it's not a problem with the contents. I'm looking deeper to see if I can get to the root of this one.
Ah, actually looking further into the trace did prove interesting: #2 0x408de157 in DCOPClient::call(QCString const&, QCString const&, QCString const&, QMemArray<char> const&, QCString&, QMemArray<char>&, bool, int) ( this=0x80553a8, remApp=@0xbfffe4f0, remObjId=@0xbfffe4f8, remFun=@0xbfffe3e0, data=@0xbfffe480, replyType=@0xbfffe528, replyData=@0xbfffe520, useEventLoop=false, timeout=-1) at dcopclient.cpp:1680 Which is: QApplication::eventLoop()->processEvents( QEventLoop::WaitForMore); So it's actually hanging intentionally -- it's just that the event never hits.
Subject: [patch] Making KDE work with (web based) proxy scripts again For some time at work we've been unable to use KDE's autoconfiguration based on a specific URL. This was reported in bug #69026. The basic problem is that kded is that when Konq browses to a certain URL KProtocolManager::proxyForURL() is called on that URL which queries kded for the proxy. kded then finds out that the file it's looking for (http://proxy:8083) is using the http protocol, so it calls KProtocolManager::proxyForURL() to determine how to fetch itself. ;-) This would probably end up as an infinite loop if there wasn't a wait call in one of the DCOP calls. The attach patch makes sure that if proxyForURL() is called on proxyConfigScript() (in our case http://proxy:8083) that it returns "DIRECT" rather than trying to look up the proxy to handle that with. Also along the way I realized that KURL::url() (and as such KURL::equals()) doesn't actually strip or add the trailing slash as indicated by the optional parameter in the case that there is no path. i.e. KURL("http://proxy:8083").equals("http://proxy:8083/"), true) == false I'm guessing that the change to KURL is wrong, because it seems like for the way it was coded that there must be something that assume trailingSlash() won't strip or append a slash if the path is empty, but since that's counterintuitive I'll leave that to someone else to confirm. Thoughts? IMHO having this broken is a pretty big deal... -Scott Created an attachment (id=4148) fix-proxy-config.patch
Subject: kdelibs CVS commit by wheeler: Don't try to call KProtocolManager::proxyForURL() on the proxy configuration URL as this causes kded (and whatever is trying to view the URL) to hang. Also fixed a buglet in KURL so that KURL("http://foo/").equals("http://foo, true) (the last true indicating that trailing slashes should be ignored) returns true. Ok'ed by Waldo. Also closing #69026 as this is the bug as Helge reported it. If there are further problems / requests they should really be filed separately. CCMAIL:69026-done@bugs.kde.org M +1 -3 kdecore/kurl.cpp 1.264 M +2 -1 kio/kio/kprotocolmanager.cpp 1.135 --- kdelibs/kio/kio/kprotocolmanager.cpp #1.134:1.135 @@ -246,5 +246,6 @@ QString KProtocolManager::proxyForURL( c { QString p = url.protocol(); - if ( p.startsWith( "http" ) || p == "ftp" || p == "gopher" ) + if ( ( p.startsWith( "http" ) || p == "ftp" || p == "gopher" ) && + ! url.equals( proxyConfigScript(), true ) ) DCOPRef( "kded", "proxyscout" ).call( "proxyForURL", url ).get( proxy ); } --- kdelibs/kdecore/kurl.cpp #1.263:1.264 @@ -1223,7 +1223,5 @@ static QString trailingSlash( int _trail { int len = result.length(); - if ( len == 0 ) - result = QString::null; - else if ( result[ len - 1 ] != '/' ) + if ( len == 0 || result[ len - 1 ] != '/' ) result += "/"; return result;
Subject: Re: [patch] Making KDE work with (web based) proxy scripts again On Tuesday 13 January 2004 14:51, Scott Wheeler wrote: > For some time at work we've been unable to use KDE's autoconfiguration > based on a specific URL. This was reported in bug #69026. > > The basic problem is that kded is that when Konq browses to a certain URL > KProtocolManager::proxyForURL() is called on that URL which queries kded > for the proxy. kded then finds out that the file it's looking for > (http://proxy:8083) is using the http protocol, so it calls > KProtocolManager::proxyForURL() to determine how to fetch itself. ;-) > > This would probably end up as an infinite loop if there wasn't a wait call > in one of the DCOP calls. Why ? The proxyscout code will always detect the URL is the same as the one it is trying to download and return "DIRECT". See kdelibs/kio/misc/kpac/proxyscout.cpp around line 66. > The attach patch makes sure that if proxyForURL() is called on > proxyConfigScript() (in our case http://proxy:8083) that it returns > "DIRECT" rather than trying to look up the proxy to handle that with. Not yet. We all understand the problem, but we do not know the cause... Can you please add debug statements to the below the line mentioned about and see if you ever get to it when the proxy attempts to download the script file... BTW, I cannot duplicate this at all! It works fine for me... There must be something else going on here....
Subject: Re: [patch] Making KDE work with (web based) proxy scripts again On Tuesday 13 January 2004 23:30, Dawit A. wrote: > Why ? The proxyscout code will always detect the URL is the same as the one > it is trying to download and return "DIRECT". See > kdelibs/kio/misc/kpac/proxyscout.cpp around line 66. [...] > Not yet. We all understand the problem, but we do not know the cause... > Can you please add debug statements to the below the line mentioned about > and see if you ever get to it when the proxy attempts to download the > script file... BTW, I cannot duplicate this at all! It works fine for me... > There must be something else going on here.... Ok, I asked Waldo to look over this one earlier and got him to approve it so I already checked it in, (as I would rather have it working and a little unclear than not working and unclear for the release) but if we come up with a cleaner solution I'd be more than happy to revert that. However, looking at the line you point out: if ( m_downloader && url == m_downloader->scriptURL() ) return "DIRECT"; I'm pretty sure that I see the problem -- the equality operator here won't work in a lot of situations because the URL as one of the two (don't remember which off the top of my head -- I can only test this at work) is usually padded with a trailing "/" and the equality operator will return false. i.e. in our case "http://proxy:8083" != "http://proxy:8083/" Tomorrow I'll try to switch the line above to use: url.equals( m_downloader->scriptURL(), true ) instead and see if that fixes things. (And the above would only work after the small KURL change that I checked in.) - -Scott
Subject: kdelibs/kio CVS commit by wheeler: Now the correct fix for the proxy resolution stuff. This makes sure that the comparison for finding the proxy for a given URL isn't the same as the proxy configuration URL. This version makes it ignore a trailing "/" at the end of the URLs (and reverts my earlier change to do the same in the wrong place). Approved by Dawit A CCMAIL:69026@bugs.kde.org M +1 -2 kio/kprotocolmanager.cpp 1.136 M +1 -1 misc/kpac/proxyscout.cpp 1.5 --- kdelibs/kio/kio/kprotocolmanager.cpp #1.135:1.136 @@ -246,6 +246,5 @@ QString KProtocolManager::proxyForURL( c { QString p = url.protocol(); - if ( ( p.startsWith( "http" ) || p == "ftp" || p == "gopher" ) && - ! url.equals( proxyConfigScript(), true ) ) + if ( p.startsWith( "http" ) || p == "ftp" || p == "gopher" ) DCOPRef( "kded", "proxyscout" ).call( "proxyForURL", url ).get( proxy ); } --- kdelibs/kio/misc/kpac/proxyscout.cpp #1.4:1.5 @@ -64,5 +64,5 @@ namespace KPAC // Never use a proxy for the script itself - if ( m_downloader && url == m_downloader->scriptURL() ) return "DIRECT"; + if ( m_downloader && url.equals( m_downloader->scriptURL(), true ) ) return "DIRECT"; if ( m_script ) return handleRequest( url );
Problem still persists on 3.3.1 for me. I'm on the domain "effenberger", and wpad.effenberger is available as host. http://wpad.effenberger/proxy.pac sends a correct proxy.pac file. However, no proxy is being found. Entering the proxy.pac path manually works fine.