Kacheong Poon wrote:
James Carlson wrote:For WPAD to work, you need to have at least one of two things: - a host named "wpad.foo.com" (where "foo.com" is replaced by something that is in the configured DNS search path) that has a web server running and has a document named "/wpad.dat" with the PAC info. - a DHCP server offering up site-local option 252, with the contents of the string set to a URL that gives you the PAC information. I don't see where any special DHCP action on NWAM's part helps here. In both cases, these are bits of infrastructure that the network must be configured to have.Maybe I've misunderstood the WPAD method... The method first uses DHCP to obtain a CURL (which is the URL to retrieve the configuration file). This is similar to the "Automatic proxy configuration URL" in Firefox/Mozilla. So if NWAM just returns something like file:///etc/inet/nwam/proxy.pac to the DHCPINFORM request, I thought the client would just use the URL to get the PAC file. I checked the WPAD draft carefully. So it seems that the method used in the CURL must be through HTTP. I don't know if Firefox/Mozilla is "smart" enough to understand a "file:///..." CURL...
Knowing nothing about the WPAD method, I'm still bothered by the above; NWAM should not be in the business of responding to DHCPINFORM requests, because then you're trying to hijack DHCP server operations, which of course creates yet more problems. So can you clarify what you really mean?
Dave _______________________________________________ networking-discuss mailing list [email protected]
