Bug 69026 - kio_kpac could be more intelligent on slightly misconfigured systems
Summary: kio_kpac could be more intelligent on slightly misconfigured systems
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 3.2-beta
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 60885 69631 70133 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-11-25 22:08 UTC by Helge Deller
Modified: 2004-11-06 20:48 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
JS-Script used is at work by my employer (784 bytes, text/plain)
2003-11-25 22:09 UTC, Helge Deller
Details
Testcase which shows that myIpAddress() is broken. (129 bytes, text/plain)
2004-01-10 13:55 UTC, Malte S. Stretz
Details
Patch for the myIpAddress() problem. (549 bytes, patch)
2004-01-10 15:26 UTC, Malte S. Stretz
Details
fix-proxy-config.patch (1.59 KB, text/x-diff)
2004-01-13 20:52 UTC, Scott Wheeler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Helge Deller 2003-11-25 22:08:18 UTC
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.
Comment 1 Helge Deller 2003-11-25 22:09:36 UTC
Created attachment 3405 [details]
JS-Script used is at work by my employer
Comment 2 Helge Deller 2003-12-05 23:10:13 UTC
really needs to be fixed before release.
Comment 3 Dawit Alemayehu 2003-12-06 07:17:06 UTC
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
Comment 4 Stephan Kulow 2003-12-06 10:26:31 UTC
so far all you have is a "it seems"
Comment 5 Helge Deller 2003-12-06 12:25:57 UTC
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
Comment 6 Helge Deller 2003-12-08 20:35:12 UTC
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.
Comment 7 Dawit Alemayehu 2003-12-08 21:50:09 UTC
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.
Comment 8 Malte S. Stretz 2003-12-09 01:31:00 UTC
*** Bug 69631 has been marked as a duplicate of this bug. ***
Comment 9 Helge Deller 2003-12-09 21:25:13 UTC
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
Comment 10 Dawit Alemayehu 2003-12-12 20:25:04 UTC
*** Bug 70133 has been marked as a duplicate of this bug. ***
Comment 11 Dawit Alemayehu 2003-12-12 20:44:36 UTC
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...

Comment 12 Helge Deller 2003-12-17 21:02:18 UTC
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 ?
Comment 13 Dawit Alemayehu 2003-12-18 06:12:19 UTC
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...
Comment 14 Dawit Alemayehu 2003-12-18 15:40:36 UTC
*** Bug 60885 has been marked as a duplicate of this bug. ***
Comment 15 Malte S. Stretz 2003-12-18 21:12:24 UTC
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.
Comment 16 Dawit Alemayehu 2003-12-19 21:53:10 UTC
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.
Comment 17 Malte S. Stretz 2003-12-21 14:06:52 UTC
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.
Comment 18 Stephan Kulow 2004-01-10 12:40:19 UTC
"these problems are actually misconfigurations and can't really be fixed in KDE"
Comment 19 Helge Deller 2004-01-10 12:52:32 UTC
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 ?
Comment 20 Malte S. Stretz 2004-01-10 13:43:57 UTC
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.
Comment 21 Malte S. Stretz 2004-01-10 13:55:06 UTC
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".
Comment 22 Malte S. Stretz 2004-01-10 15:08:06 UTC
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
Comment 23 Malte S. Stretz 2004-01-10 15:26:30 UTC
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?
Comment 24 Stephan Kulow 2004-01-10 19:55:23 UTC
great news! I checked KDE 3.1 and it's indeed that simply typo ;(

will commit asap
Comment 25 Stephan Kulow 2004-01-10 20:04:58 UTC
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 ) );


Comment 26 Malte S. Stretz 2004-01-11 02:21:10 UTC
The patch fixed only one aspect of this bug. Changed the summary accordingly and set to wish, reopened.
Comment 27 Malte S. Stretz 2004-01-11 02:21:50 UTC
reopen, I said :)
Comment 28 Scott Wheeler 2004-01-13 19:20:09 UTC
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.
Comment 29 Scott Wheeler 2004-01-13 19:25:32 UTC
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.
Comment 30 Scott Wheeler 2004-01-13 20:52:03 UTC
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
Comment 31 Scott Wheeler 2004-01-13 23:09:01 UTC
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;


Comment 32 Dawit Alemayehu 2004-01-13 23:30:24 UTC
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....

Comment 33 Scott Wheeler 2004-01-14 00:46:19 UTC
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

Comment 34 Scott Wheeler 2004-01-15 23:05:22 UTC
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 );


Comment 35 Florian Effenberger 2004-11-06 20:48:47 UTC
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.