Warning, /frameworks/kio/src/kpac/README.wpad is written in an unsupported language. File is not indexed.

 Web Proxy Auto Discovery (WPAD)
 ===============================
 
 This README is intended for network administrators who want to enable the
 users on their network to fully automatically find the proxy settings.
 
 Automatic proxy discovery works in two steps:
 1) Find a configuration script
 2) 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:
 
 1. 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.
 
 2. 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.
 
 If you have further questions or comments, please contact me: Malte
 Starostik <malte@kde.org>