Last Comment Bug 30387 - Proxy: manual pref requires hostnames not URLs (http://)
: Proxy: manual pref requires hostnames not URLs (http://)
Status: RESOLVED WONTFIX
relnote-user
: relnote
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: All All
: P2 enhancement with 6 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 49018 178337 181152 (view as bug list)
Depends on: 53080
Blocks:
  Show dependency treegraph
 
Reported: 2000-03-03 19:31 PST by Giacomo Magnini
Modified: 2015-12-10 18:26 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (4.65 KB, patch)
2001-07-24 07:04 PDT, Chase Tingley
no flags Details | Diff | Review

Description Giacomo Magnini 2000-03-03 19:31:31 PST
Using build 2000030313 under Win98.
Prepending the name of the proxy in the configuration with http:// will
stops mozilla from accessing any site.
So: www.proxy.com works
    http://www.proxy.com does not.
Restoring plain name will make mozilla happy again.
It seems to work just fine under linux.
Comment 1 Asa Dotzler [:asa] 2000-03-03 19:39:50 PST
Confirming to put this in better view.
Comment 2 Gagan 2000-03-07 01:12:12 PST
so if I understand write you are setting your proxy to be http://foo instead of 
just foo? That seems wrong... but I will allow you to help me understand the 
problem correctly.
Comment 3 Giacomo Magnini 2000-03-07 10:47:56 PST
The behaviour is just like you described. If it's the wrong way to configure the
proxy, then then instructions coming from my ISP are lame. Anyway it worked fine 
under NS 4.x. So maybe this is not a bug, but an idiot-proof enhancement...
Comment 4 Giacomo Magnini 2000-03-18 06:14:08 PST
Just an additional note: the mozilla profile manager will not convert the 
http://foo (which works in NS 4.x) in the correct one, so mozilla will be 
misconfigured.
Comment 5 Warren Harris 2000-04-17 22:05:03 PDT
Moving beta2 bugs out of M18.
Comment 6 leger 2000-05-01 18:22:19 PDT
Putting on [nsbeta2-] radar. 
Comment 7 Gagan 2000-07-11 17:09:12 PDT
relnote: remove any leading http:// in proxy configurations in prefs.js
Comment 8 Asa Dotzler [:asa] 2000-07-12 17:15:46 PDT
removing self from cc:
Comment 9 Jordan Crouse 2000-08-08 08:02:21 PDT
Still very very very broken in Mozilla build 2000080712 (on Linux).  Automatic
proxy doesn't work at all (with or without HTTP).  The result is the same,
Mozilla just doesn't try to access any sites.  Manual proxy works just fine.
Comment 10 Jordan Crouse 2000-08-08 08:07:07 PDT
An additional comment:  When Mozilla is started with automatic proxy settings
(which don't work), and then is switched to a manual proxy setting, URLs typed
into the address bar still do not work, but all links, bootmarks, and shortcut
buttons do work.

To fix it, you gotta shutdown mozilla. When you come back, Mozilla is happy again.
Comment 11 Rich Burridge 2000-08-10 17:44:00 PDT
Some comments on this problem:

* If you have automatic proxy configuration set, then when you try to go
  to a URL in the Location: text field, it calls the section of code in
  .../mozilla/netwerk/base/src/nsProtocolProxyService.cpp about line 255:

        nsCOMPtr<nsIProxyAutoConfig> pac =
            do_CreateInstance(NS_PROXY_AUTO_CONFIG_PROGID, &rv);

This code is failing because the NS_PROXY_AUTO_CONFIG_PROGID component
is not registered.

* The implementation of nsIProxyAutoConfig is done by:
  .../mozilla/netwerk/base/src/nsProxyAutoConfig.js
  Yet, from looking at the Makefile in this directory, this JavaScript 
  component is not placed in .../mozilla/dist/bin/components, nor the
  .../mozilla/netwerk/base/public/_xpidlgen/nsIProxyAutoConfig.xpt file.

* If these files are linked into the .../mozilla/dist/bin/components
  directory, and regxpcom run, the code in nsProtocolProxyService.cpp 
  still fails for some unknown reason.

This problem is still under investigation. Suggestions from folks more
familiar with the code (hi gagan! ;-), are very welcome.

Comment 12 Rich Burridge 2000-09-18 07:48:51 PDT
Changing the priority of this bug to P2. Getting "file:/" style URL's
working with Automatic Proxy Configuration .pac files is essential to
the internal deployment of Netscape 6 internally here at Sun.
Comment 13 Gagan 2000-09-18 11:53:28 PDT
Rich: The PAC is a separate problem. In order to get that working see the notes 
at http://www.mozilla.org/docs/netlib/pac.html They are not the best notes but 
should allow you to get PAC working. 
Comment 14 Rich Burridge 2000-09-18 12:31:52 PDT
Thanks Gagan. So, should we open up a separate new bug for the "file:/" PAC
problem? One of my team is looking at this at the moment, and I wouldn't
be surprised if he doesn't have a fix by the end of the week. 
Comment 15 Gagan 2000-09-18 12:52:50 PDT
I don;t have the bug number handy but there is a PAC related bug which basically 
describes the problem of not being able to specify ANY URL for the PAC 
configuration. Currently the only way PAC works is if you copy over the contents 
of that PAC file to the nsProxyAutoConfig.js file. So to answer your question, 
yes feel free to create a new bug but be aware that it would be marked a dup of 
the one I just described (and can't find)
Comment 16 Rich Burridge 2000-09-18 13:29:58 PDT
Thanks. I couldn't find it either. I've opened 53080 for the "file:/"
problem, and assigned it to Akhil Arora who is just started looking at it.
Comment 17 Michael Ward 2000-11-22 12:31:24 PST
*** Bug 60287 has been marked as a duplicate of this bug. ***
Comment 18 Akhil Arora 2000-11-22 12:47:53 PST
the suggested patch for 53080 fixes this problem. this bug should be closed as 
duplicate.
Comment 19 Gagan 2000-12-08 00:40:40 PST
http bugs to "Networking::HTTP"
Comment 20 benc 2001-03-07 16:11:40 PST
Changed summary to say "automatic", so we know we are talking about the same
thing :)
Comment 21 Darin Fisher 2001-04-06 23:21:24 PDT
gagan (mr. pac-man): sending this your way ;-)
Comment 22 Gagan 2001-04-09 11:24:40 PDT
this bug relies on bug 53080 landing.
Comment 23 benc@chuang.net 2001-04-13 01:11:19 PDT
I have reviewed this bug, and realized that this original problem description
deals with putting a URL rather than a fqdn into the manual proxy fields. (PAC
never worked, so if the reporter says it worked w/ hostnames, it was manual proxy).

I have changed this summary (external-ben corrects internal-ben...), and I'll
look at it soon. All the PAC issues sseem to have their own bug.

My initial feeling is that we should have better documentation first, and add a
friendly error message second (other errors probably are higher priority...)
Comment 24 Chase Tingley 2001-07-05 10:28:31 PDT
Adding 4xp since this apparently works in 4.x.
Comment 25 benc 2001-07-05 11:50:28 PDT
IMO: this should have never worked, because you are pointing to a network
socket, not a URL.

However, I will not mark it invalid since it is a 4xp.
Comment 26 Chase Tingley 2001-07-24 07:04:12 PDT
Created attachment 43359 [details] [diff] [review]
patch
Comment 27 Chase Tingley 2001-07-24 07:07:50 PDT
Obviously, these fields are supposed to take qdns instead of urls. However, we
have no mechanism for providing feedback to the user, and a 4xp bug in
preferences strikes me as having an implicit profile migration issue as well. 
It seemed easier just to use the educated guesswork of nsStdURLParser to pull
the hostname out of the field rather than trusting the value blindly.  

Please review, especially to make sure I'm not leaking strings.  (I haven't done
much with nsXPIDLCString before.)
Comment 28 benc 2001-07-24 09:51:01 PDT
If we had good error checking, then we could error in prefs and when they try to
hit the network w/ a bad pref.

that would solve the migration problem too.
Comment 29 benc 2001-07-31 13:23:07 PDT
RELNOTE:

Manual Proxy does not accept URLs

Communicator 4 would accept a URL (http://proxy) in the manual proxy
configuration. Netscape 6 only accepts hostnames. If you migrate a Communicator
4 profile, you will need to change the settings by hand.
Comment 30 benc 2001-08-16 02:28:49 PDT
*** Bug 49018 has been marked as a duplicate of this bug. ***
Comment 31 benc 2001-08-16 02:30:04 PDT
something to look at again...
Comment 32 benc 2001-08-23 13:34:29 PDT
-> networking, qa to me.
Comment 33 Hong Kwon 2001-10-09 19:04:23 PDT
marking nsenterprise-; will be reevaluated for nsenterprise in future release.

Comment 34 benc 2002-04-20 10:51:30 PDT
gagan: chase has a patch, lets either WONTFIX or change the milestone.

I vote for WONTFIX. I dislike these "4xp was stupid so we need to be also" bugs.

I also went back and confirmed this in Communicator 4, and doing a full URL
parse of manual configs completely confuses the auth dialog, it says things like
"http://proxy:8080:0"

The relnote text was really confusing to me, so I sumitted the following correction:

"Communicator 4 allowed URL's in manual configuration, but Mozilla does not. If
you migrate a profile configured this way, you will need to change the URL to a
hostname and port number."
Comment 35 benc 2002-11-05 04:32:40 PST
*** Bug 178337 has been marked as a duplicate of this bug. ***
Comment 36 benc 2002-11-21 10:39:08 PST
*** Bug 181152 has been marked as a duplicate of this bug. ***
Comment 37 benc 2003-10-16 22:12:54 PDT
-> defaults.

Darin, can I suggest won't fix for this bug? We have no reports of this problem,
and profile migration of 4xp is not a big deal anymore.
Comment 38 Darin Fisher 2003-10-16 22:37:52 PDT
i don't know... you'd be surprised.  i hear some companies still use 4.x for
internal sites, etc.  and, this is really easy to fix.  i don't mind keeping it
as a future bug.
Comment 39 Jo Hermans 2004-09-08 01:34:28 PDT
*** Bug 258378 has been marked as a duplicate of this bug. ***
Comment 40 benc 2004-09-16 09:06:02 PDT
Actually, I found a message while cleaning out my mailbox, which I can't seem to
find (or maybe I decided they should just comment in the bug if they really
meant it), where they took me to task as an ignorant lout because the original
unix preferences were URLs in the environment variable, and these preferences
were read from the firing shell when navigator was launched from UNIX.

heh.

This really should be wontfix for mozilla, and FF can use the new migrator code.
Comment 41 Ian Batterbee 2005-12-28 12:54:59 PST
Can I suggest that if this is going to be a WONTFIX, that the direct reference to it in the release notes under Known Issues is removed. I wouldn't have even known about this issue if it wasn't described there.

http://www.mozilla.org/releases/mozilla1.7.12/known-issues.html#proxies

Note You need to log in before you can comment on or make changes to this bug.