PAC: config - hostnames do not work, need URL

VERIFIED WONTFIX

Status

()

Core
Networking
--
minor
VERIFIED WONTFIX
17 years ago
14 years ago

People

(Reporter: Johannes Koskinen, Unassigned)

Tracking

Trunk
x86
Windows NT
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9+) Gecko/20010527
BuildID:    2001052708

If you use an automatic proxy settings and give an URL without http://-prefix
(for example, www.tut.fi...) the connection refuses always.

Reproducible: Always
Steps to Reproduce:
1.Set an automatic proxy address without http-prefix
2.restart mozilla (?)
3.Try to connect www.mozilla.org

Actual Results:  I get a dialog box with connection refused

Expected Results:  IE can use an automatic proxy address without http-prefix.

Comment 1

17 years ago
I'm not sure what we can do here, PAC files are FILES, that need to be specified
w/ URLs. Unless you can document the exact behavior of IE (what does it request
if you type in just a hostname), this will probably be marked "INVALID."
Keywords: qawanted
(Reporter)

Comment 2

17 years ago
This is the point:
The IE works right even if I set an automatic configuration script address to
www.tut.fi/network/web/cache_tut.pac
but mozilla needs the address in format
http://www.tut.fi/network/web/cache_tut.pac
^^^^^^^

The latter is right of course, but all other www-pages can be assigned without 
http-prefix, so at least the browser should generate a warning instead of 
refusing to connect.
Severity: normal → minor

Comment 3

17 years ago
I think that that is needless liberality, since a PAC file should be a
user-entered value that comes from a presumably URL-literate proxy administrator.

Then again I have been wrong.

I would think that maybe pre-populating the field with: "http://" would be solution.

Error messages on non-URL entries would be another solution.

Comment 4

17 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 5

17 years ago
-->jpm
Assignee: neeti → jpm

Comment 6

17 years ago
adding PAC:
Summary: Automatic proxy won't work without http://-prefix → PAC:Automatic proxy won't work without http://-prefix

Updated

17 years ago
QA Contact: benc → pacqa

Comment 7

17 years ago
Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka
Assignee: jpm → serge

Updated

17 years ago
Blocks: 79893

Updated

17 years ago
Depends on: 90308

Comment 8

16 years ago
I have this same problem. I feel I should point out that this worked in Netscape
4.x. In fact, my settings were migrated to Mozilla with this intact.

Comment 9

16 years ago
Out of the blue, I realized how this worked in the past (or should work if we do
this...

For mozilla, I'm somewhat unsympathetic. For commercial products, I can see the
desire to make this field less cryptic in appearance.

We need to take the string in the box and call URIfixup.

This has a lot of potentially strange concepts (because URI fixup is a strange
thing in some ways...)

Who wants to add some usability people to this bug?

Comment 10

16 years ago
to default owner
Assignee: serge → new-network-bugs

Comment 11

16 years ago
qa to me.
-qawanted +4xp +nsenterprise

RESOLVED/WONTFIX.

If someone is really opposed to this in Mozilla, you can re-open and make your case.

"A URL is a URL"
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Keywords: qawanted → 4xp, nsenterprise
QA Contact: pacqa → benc
Resolution: --- → WONTFIX

Comment 12

16 years ago
*** Bug 161908 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
I know what this has been resolved as WON'T FIX, but could I lobby for a
*warning* at least?  This just fails silently with a bad url string.  

Comment 14

15 years ago
Sorry, didn't drill deep enough.  Ignore comment.

Comment 15

15 years ago
I had trouble finding this bug, so I've tried to improve the searchability.
Summary: PAC:Automatic proxy won't work without http://-prefix → PAC: config - hostnames do not work, need URL

Comment 16

15 years ago
*** Bug 96149 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Keywords: verifyme

Comment 17

14 years ago
V/wontfix: fixed in FF-only, see bug 243397.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.