If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Proxy: FTP does not show proxy auth (when proxy sends 407)

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Networking: FTP
P3
normal
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: Matt Behrens, Assigned: dougt)

Tracking

({testcase})

Trunk
mozilla0.9.1
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed on branch, URL)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20000913
BuildID:    2000091317

FTP-thru-proxy now works, unless you are using a proxy server and said proxy
server requires you to authenticate yourself -- and you have not yet
authenticated for this session.

Reproducible: Always
Steps to Reproduce:
1. start Moz
2. try to go to an FTP url (spinner spins, nothing)
3. go to an HTTP url, enter proxy username/password
4. try to go to an FTP url (success!)

When I sniffed traffic on my machine, I found that if I had not yet entered
proxy credentials, Moz was indeed trying to contact the proxy server but didn't
know what to do with the 407, so it gave up.

[Note: As far as severity goes, I had some trouble deciding.  Obviously there is
a workaround, but that workaround would not be considered acceptable for
deployment of Moz in organizations using proxies that require user
authentication.  I hope I made a fair decision.]
(Reporter)

Updated

17 years ago
Summary: ftp-thru-proxy does not prompt for authententication → ftp-thru-proxy does not prompt for authentication
Matt.Behrens@kohlerco.com - are you still seeing this problem on recent builds 
of Mozilla? If so, we'll confirm this bug.

Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

17 years ago
Yes, it's still an issue with 2000102220 (Win32).

Comment 3

17 years ago
ftp bugs to component:ftp
Assignee: gagan → dougt
Component: Networking → Networking: FTP
Target Milestone: --- → M19

Updated

17 years ago
Blocks: 61691
(Assignee)

Updated

17 years ago
Blocks: 62353

Comment 4

17 years ago
This problem is also happening on the HPUX build, and with the latest Linux
build (2001011008) too.

Steps to reproduce:
1) start browser
2) setup proxy connections in preference to york.mcom.com:3128
3) go to URL ftp://username@hostname (e.g. ftp://ftp-admin@ftp1.netscape.com)

Result: nothing happens
Expected: a dialog box to enter the password

Comment 5

17 years ago
I'm also seeing this on the Mac.  I'd like to change Platform and OS to All, but
bugzilla ain't letting me.
(Assignee)

Updated

17 years ago
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1

Comment 6

17 years ago
Please set platform, OS ->all Seeing it on Linux too.
(Reporter)

Comment 7

17 years ago
Sorry, wasn't paying attention for a bit :-)
OS: Windows NT → All
Hardware: PC → All
(Assignee)

Updated

17 years ago
Depends on: 76866
(Assignee)

Updated

17 years ago
Whiteboard: fixed on branch
(Assignee)

Comment 8

17 years ago
Fixes checked in.  QA please verify.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
Unable to verify with Linux Build ID 2001051508.

Tested on proxy server : frame.packetgram.com:443

No dialog window prompt for authentication.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 10

17 years ago
does an auth dialog come up when going to a http site?  If not, than we need to
configure frame.packetgram.com:443 to do auth.

Ben, any thoughts about adding a port that is always for auth testing?  
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 11

17 years ago
qa to me.

proxy.packetgram.com:443 is already doing ftp proxy, and it uses auth by default.

Since most people have been using it for http as well, it you need to configure
JUST ftp and not http proxy to get a clean look at the problem. (I've been
trying to file a bug on a similar problem, and if you proxy auth for http,
mozilla seeems to use it for ftp on the same proxy server.)
QA Contact: tever → benc

Comment 12

17 years ago
Tested on proxy server york:3128 which doesn't auth at default. When connecting
to other http or ftp site that requires auth still doesn't prompt auth dialog
display.

Comment 13

17 years ago
SERVER UPDATE:
proxy auth was not on for ftp URLs, I have fixed that. You can now attempt to
get an ftp URL via proxy.packetgram.com:443.

Make sure http proxy is OFF so you don't end up sharing the auth credentials.

Comm 4 - will show auth dialog
mozilla - will not show auth dialog

The reason this happens is the proxy server is returning a 407, but the
ftp+proxy module does not throw up a proxy auth dialog.

Here's my log file, the "407" is the HTTP response

208.12.40.178 - - [15/May/2001:17:58:58 -0700] "GET ftp://frame.packetgram.com/
HTTP/1.1" 407 271 - - - - 323 209 - - - - FIN - -

With communicator, if you type in the correct username:password, the log file
shows a "200" from the successful connection (Netscape Proxy globs the previous
407's into this record if session was eventual authed successfully).

208.12.40.178 - test [15/May/2001:18:05:44 -0700] "GET
ftp://frame.packetgram.com/ HTTP/1.0" 200 117 200 117 - - 351 115 - 115 0 DIRECT
FIN FIN DO-NOT-CACHE

Jimmy:
This is a separate (but probably related problem, where HTTP 401's from the
proxy are not handled. See bug: 81110

DougT:
Based on this new info, do you want me to check a certain build for a fix, or is
this a new problem?
Summary: ftp-thru-proxy does not prompt for authentication → Proxy: FTP does not show proxy auth (when proxy sends 407)
(Assignee)

Comment 14

17 years ago
sounds like a new problem.

Comment 15

16 years ago
VERIFIED:
+testcase - I hacked the proxy functional test to suggest each protocol needs
the auth handlers teseted individually. Right now it is a template of
suggestions + a list of protocols.

Mozilla 0.9.5, allplats
Status: RESOLVED → VERIFIED
Keywords: testcase
You need to log in before you can comment on or make changes to this bug.