changed subject to make it more readable. Just tested FreeBSD 6.1-STABLE w Firefox 18.104.22.168 and I have the same results as Windows 2000 and Windows XP
OS: Windows XP → All
Summary: doesn't use FQDN of the WPAD URL from DHCP server and automatic proxy configuration fails → automatic proxy config doesn't use FQDN of WPAD URL from DHCP
Yup can configm that it doesn't work. I have a hardware loalanced wpad service configured here which we're about to roll out for ie users. I've configured a virtual server with a fqdn name of wpad.hull.ac.uk. Name is hosted on 3 real servers and the front end load balancer splits incoming requests over the 3 servers. Logging is enabled with a directory for each virtual host configured on the server. There is also a "default" log directory for any requests that come in that don't specify one of the virtual hosts. In additon to the FQDN DNS entry, I've set up option 252 on our dhcp server to pass back a url form the wpad.dat string. I'm running firefox 22.214.171.124 and 2.0 on various platforms and the incoming request always appears in the default server log file. The second problem is that although the web server says that its handed out my wpad.dat, the browser still attempts to get to the outside world directly and not via my web caching service. Selecting a specific autoproxy config file works just fine.
The WPAD implementation does not use DHCP but simply requests the URL http://wpad/wpad.dat (see bug 28998 comment 97). Adding "ServerAlias wpad" to your VirtualHost might help you. The missing DHCP support is described in bug 356831, so I am marking this a duplicate.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 356831
There are actually two bugs here. I'm most concerned that our current implementation doesn't work with the virtual server config. If you request: "http://wpad/wpad.dat", what does your web server log say? My guess is that it gives the browser: http://example.com/wpad.dat I think there is an option in the logging where you can turn on logging the hostname of the request. You should see us request just "wpad". This isn't ideal, because Necko doesn't support the idea of an application-level default domain. If it loaded the default domain from the OS and used it, it could do what you wanted.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Changing summary. Maybe fixing the problem comes from implementing DHCP support, but we still need to understand how we fail in this environment.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: automatic proxy config doesn't use FQDN of WPAD URL from DHCP → WPAD: automatic proxy config doesn't use FQDN in URL
You need to log in before you can comment on or make changes to this bug.