Automatic Proxy Discovery
Many networks allow access to the internet through a proxy
server. Proxy servers allow the administrators to restrict access
Konqueror is capable of automatically discovering and using
properly configured server on your network, which gives you certain
advantages:
Users don't have to know about or configure proxy
services in order to use them.
It's possible to change the proxy configuration of every browser
from a single place.
You can have specific traffic going through specific proxy
servers, based on who is accessing them.
Provide a list of local servers, that can be accessed directly
without the proxy.
Automatically enable fallback services, in case the specified
proxy server is unavailable.
Of course you can do most of those things in any case, but
having the proxy information automatically discovered allows you to
keep all these things transparent to the user.
Automatic proxy discovery works in two steps:
Procedure 7.1.
Find a configuration script
Determine a proxy to use by running that
script
The configuration script is a PAC
(JavaScript) file just as in plain Proxy Auto Configuration as
described here:
http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html.
The WPAD part of the process (#1 above)
described here is about how to find this script without having the
users enter its URL into the proxy settings. (All they have to do in a
WPAD-enabled network is to select
Automatically detected script file in KDE's
proxy setup.
There are two alternative ways to discover the
PAC script's URL implemented in
KDE:
- DHCP based autodiscovery
If you are running a DHCP server on your
network anyway, you might want to use this approach; all you
have to do is to add the WPAD
option (numeric 252 or hex fc) as a string containing the URL to the
PAC script.
To do so with older versions of ISC
dhcpd, add this to
/etc/dhcpd.conf, either globally or just
for the subnets you want to enable WPAD
for:
option option-252 "http://example.com/path/to/proxyconfig.pac";
Or, for newer ISC dhcpd versions, add this globally:
option wpad code 252 = text;
and this either globally or for the WPAD subnets:
option wpad "http://example.com/path/to/proxyconfig.pac";
For other DHCP servers, please consult the
reference manual on how to add an option by number if WPAD
support is not built-in.
- DNS based autodiscovery
If you don't run a DHCP server or prefer
DNS based discovery, you
need to configure one of your hosts to have the name
wpad.example.com and make sure the PAC
script is available as
http://wpad.example.com/wpad.dat
If your network consists of several
subdomains, like a.example.com and b.example.com you can either
provide both http://a.example.com/wpad.dat and
http://b.example.com/wpad.dat or just http://example.com/wpad.dat
When a client searches for that script, it will search for a host
named wpad in its own domain, then in
the next higher level domain
until success or if only the TLD is left
(i.e. wpad.com will never be tried.)
Note that DHCP is the preferred approach
since it's more flexible than DNS as it doesn't
require a well known host name nor a fixed location
(/wpad.dat) for the PAC
script. It is also the first method tried before resorting to
DNS, so if you use DNS there
will be a noticeable delay of 5 seconds while waiting for a
DHCP reply.
However, DHCP requires a helper program,
kpac_dhcp_helper to be installed suid root. If you consider this a security
problem, just delete that program or remove its suid permissions and
use DNS instead. If the helper cannot execute as
root, the 5 seconds delay
will also go away.
