350759 - WPAD: automatic proxy config doesn't use FQDN in URL

Status: NEW

(Firefox :: Settings UI, defect)

Description

[Doug Poland]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060728 FreeBSD/i386 Firefox/1.5.0.6
Build Identifier: 

Given properly configured DHCP, DNS, and HTTP servers, Firefox does not honor the URL presented by the dhcpd.  I.e., If my wpad.dat script resides at http://wpad.example.com/wpad.dat,  firefox looks for it at http://example.com/wpad.dat.  

# grep wpad /usr/local/etc/dhcpd.conf
option wpad-url code 252 = text;
option wpad-url "http://wpad.example.com/wpad.dat\n";

% dig +short wpad.example.com
proxy.example.com.
192.168.1.13

# grep -C3 wpad /usr/local/etc/apache/httpd.conf

<VirtualHost *>
    ServerAdmin [e-mail]
    DocumentRoot /data/www/wpad
    ServerName wpad.example.com
    ErrorLog /var/log/httpd/wpad.org-error.log
    CustomLog /var/log/httpd/wpad.org-access.log combined
    AddType application/x-javascript-config .dat
    AddType application/x-ns-proxy-autoconfig .pac
</VirtualHost>


% curl http://wpad.example.com/wpad.dat
function FindProxyForURL(url, host) {
     if (shExpMatch(url,"*.example.com/*"))                  {return "DIRECT";}
     if (shExpMatch(url, "*.example.com:*/*"))               {return "DIRECT";}
     return "PROXY proxy.example.com:8040; DIRECT";
  }

When I choose "Connection Settings --> Auto-detect proxy settings for this network"  and launch firefox 1.5.0.6, firefox attempts to retrieve the wpad.dat from example.com, NOT wpad.example.com

% grep wpad.dat /var/log/http*
/var/log/httpd/www.example.com-access.log:192.168.1.103 - - [30/Aug/2006:16:18:37 -0500] "GET /wpad.dat HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6"

/var/log/httpd/www.example.com-error.log:[Wed Aug 30 16:18:37 2006] [error] [client 192.168.1.103] File does not exist: /data/www/example.com/wpad.dat



Reproducible: Always




If I choose "Connection Settings --> Automatic proxy configuration URL:" and enter http://wpad.example.com/wpad.dat then Firefox finds the configuration file, loads it, and all is good.

Comment 1

[Doug Poland]

changed subject to make it more readable.

Just tested FreeBSD 6.1-STABLE w Firefox 1.5.0.4 and I have the same results as Windows 2000 and Windows XP

Comment 2

[A.Sharaz]

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 1.5.0.7 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.

Comment 3

[Christian Schmidt]

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.

Comment 4

[benc]

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.

Comment 5

[benc]

Changing summary. Maybe fixing the problem comes from implementing DHCP support, but we still need to understand how we fail in this environment.