Closed Bug 310331 Opened 19 years ago Closed 13 years ago

WPAD:"Auto-detect proxy settings" should be set by default

Categories

(Firefox :: Settings UI, defect)

defect
Not set
minor

Tracking

()

RESOLVED WONTFIX

People

(Reporter: patryk, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Win98; pl-PL; rv:1.7.12) Gecko/20050919 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Many networks at Universities and Companys make use of proxy autodetection in
MSIE. It should be the same in Firefox. Instead, users have to set it by
themseves, which is against "auto-detection" magic.

Reproducible: Always

Steps to Reproduce:
look into Options->General->Connection settings

Actual Results:  
"Direct connection to Internet" is set.

Expected Results:  
Should be "Auto-detect proxy settings for this network".

This is very easy task to resolve, so I expect it could be introduced even to Fx
1.5 which aims to be corporate-ready.
I think it would probably be better to have a link to enable proxy autodetect on
the Server Not Found error page. I believe this is how IE does it. Or perhaps
try to auto-detect proxy settings if it can't load the home page.
I don't see what could be wrong with doing this. It doesn't break anything on my
end. That said, I don't know how this would affect others.

CC'ing darin and setting to New as I cannot find a dupe.

As to how IE does it, why not just go ahead and do the auto-detect and not run
into the problem to begin with, if auto-detect doesn't break anything of course ;)
Status: UNCONFIRMED → NEW
Ever confirmed: true
MSIE's Server Not Found page only shows steps on how to enable auto-detection,
MSIE itself has the option set by default.

I think if netadmins have special wpad.example.net domain set they obviously
want the mechanism to be working. When the network doesn't have that domain name
it won't harm in any way and work as usual (i.e. no proxy).
The issue is that enabling auto-detect proxy settings may delay the amount of
time required to load the homepage for users who do not need to use a proxy to
connect to the network.  Right now, we just load http://wpad/wpad.dat when asked
to auto-detect proxy settings, and we delay loading the user's homepage until we
get a response back from that wpad.dat request.  If loading wpad.dat takes a
while to fail (slow DNS resolution), then it might result in a bad user
experience.  So, I'm not sure what the right thing to do is.
How about we act as if we don't have any proxy settings set, fetching the home
page, etc as usual, and in the background fetch the wpad file; if we then find a
wpad file we can slide in those settings and automatically retry anything that
failed in the meantime. Would that work?
Yes, that might work.  But, wouldn't it be odd if it caused the homepage to
reload?  We went to great lengths in Firefox 1.5 to delay loading the homepage
until after the PAC file has been loaded because more often than not the PAC
file is needed in order to access the user's homepage.
Your comments made me to think of two possible resolutions.

1. Fetch wpad.dat in background and then retry any request in
"not-yet-connected" state, so if any file is already able to load without proxy,
let it finish, but all new and "not-yet-connected" to (re)load via proxy.

2. When starting Fx with fresh profile (and Import Wizard didn't import anything
about proxy settings), let the browser fetch wpad.dat file, if it successes -
set it as permanent, if it fails - set to direct.
I think turning this on by default has some impact on security.
In some setups (dhcp+ddns), people may simply not be aware about the whole wpad thing, or just think "I don't need it", so leaving the wpad name "free" in the zone, which will eventually result in somebody taking the name on the subnet...

Yeah, maybe this is the admin fault in the first place, and maybe IE allow this by default...

Plus, maybe some day, Firefox will be able to also autodetect proxy settings via dhcp; if this happens, will we need two different gui entries? What'll be the prefered (default) behavior?


Regards
> Plus, maybe some day, Firefox will be able to also autodetect proxy settings
> via dhcp; if this happens, will we need two different gui entries? What'll be
> the prefered (default) behavior?

i'm here regarding the use of DHCP for proxy config file URL autodetection
if ther's an existing bug please point me to it (i've been unable to find one so far)
as for how DHCP fits into the autodetection scheme, it's ment to be the primary method WPAD (web proxy auto detection) uses to determine where to find the configuration file, so it should all come under the same "auto-detection" banner, ie, no new setting should be needed
(In reply to comment #1)
> I think it would probably be better to have a link to enable proxy autodetect
> on
> the Server Not Found error page. I believe this is how IE does it. Or perhaps
> try to auto-detect proxy settings if it can't load the home page.
> 
I'm setting up Mac computers running OSX 10.4.6, and the auto-detect network settings just doesn't work!
I'm in an educational setting where pac files are used.
Any suggestions?
(In reply to comment #11)
> (In reply to comment #1)
> > I think it would probably be better to have a link to enable proxy autodetect
> > on
> > the Server Not Found error page. I believe this is how IE does it. Or perhaps
> > try to auto-detect proxy settings if it can't load the home page.
> > 
> I'm setting up Mac computers running OSX 10.4.6, and the auto-detect network
> settings just doesn't work!
> I'm in an educational setting where pac files are used.
> Any suggestions?
> 

It works for me. Can you check if the URL http://wpad.example.com/wpad.dat is valid (replacing example.com with your own domain) ? That's what auto-detect is trying to load.
After reading through these comments, I think there are some good points made on both sides of the argument, but I'd like to cast my vote with auto-detect by default on a new profile as Patryk Szczyglowski suggested. 

I manage a large network where we don't have any direct control over the host computers and need to require all users to use the proxy server. As more users are using Firefox we've seen an increase in support calls because it's not the default. I think Patryk's suggestion is a nice compromise (a one time delay when first installing firefox should minimize the impact to the user and make my, and others in the same situation a lot happier) 
Shouldn't the default rather be to do whatever the OS, resp. in Windows' case MSIE, has been configured to? See bug 218944 for making this possible under Windows. For Linux and Mac, this should even already be possible as of Firefox 3.0.
This conflicts w/ bug 416274.

Also, I think the current wpad implementation is not sufficiently robust to be the default, esp. since we don't have DHCP support yet.
Summary: "Auto-detect proxy settings" should be set by default → WPAD:"Auto-detect proxy settings" should be set by default
Hello, bug 368194 is a duplicate as Jun Wang reported in the comments. I can not mark it as "duplicate", anyone can ?
what I did to fix it was after completely removing the program that created the problem (a proxy program to switch your IP) I edited the user.js and prefs.js found in C:\Documents and Settings\*your profile*\Application Data\Mozilla\Firefox\Profiles\*default folder* (mine is C:\Documents and Settings\Shawn\Application Data\Mozilla\Firefox\Profiles\25ejt7lb.default). before editing user.js and prefs.js MAKE COPIES of them in case something screws up. while firefox is closed right click on prefs and click edit. it should open in notepad, then go into Edit>Find (in notepad), type in "network.proxy.type" then hit "find next". make sure that the number after it is a 4 like this: user_pref("network.proxy.type", 4);
then go File>Save

then edit the user.js file, and do the same thing as in the prefs file. find "network.proxy.type" and make sure that there is a 4 after it.
This conflicts with bug 500983 (use system proxy settings as the default)
Useless because of bug 500983.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.