[FIX]Cannot download files via ftp

VERIFIED FIXED in mozilla1.1beta


17 years ago
3 years ago


(Reporter: beanladen, Assigned: bzbarsky)



Firefox Tracking Flags

(Not tracked)




(5 attachments)



17 years ago
RC3/Sun Sparc/Solaris 8/PatchCluster 1/FTP over proxy

Mozilla cannot download any file via ftp !
1. Goto ftp://ftp.hp.com/pub/
2. Click right mouse on index.html
3. Try 'save link target to'
4. Some popup saying 'Cannot download because link has been removed...'

Download file in step 4.

This works on Linux and all other browsers.

When the ftp directory has an http interface (e.g, goto http://ftp.hp.com/pub),
the same files can be downloaded.

This is a major fault and should be fixed very quickly !

Comment 1

17 years ago
If I run an ftp program index.html is shown as a directory
drwxrwxr-x   2 32227    4436        8192 Oct 23  1998 hpliterature
drw-rw-r--   2 32227    4436          96 May  8  2000 index.html
drwxrwxr-x   5 32227    4436        8192 Mar 18  1999 information_storage
and if I try to get it
ftp> binary
200 Type set to I.
ftp> get index.html
200 PORT command successful.
550 index.html: not a plain file.
whereas a different ftp program works fine

   200 Type set to I.
PORT 213,120,36,192,6,239
   200 PORT command successful.
RETR index.html
   150 Opening BINARY mode data connection for index.html (335 bytes).
   226 Transfer complete.

Comment 2

17 years ago
The problem appears to be a problem with *one* of the round robin
servers for ftp.hp.com ( which has /pub/index.html marked as
a directory, whereas on the other 6 it is a file.

Comment 3

17 years ago
Ehm, this URL was meant to be an example, odd that it
is that special anyway. The problem appears on ANY file
from ANY server. Take one of your choice.
(Keep in mind that I must use a proxy for downloading)
Ah, you use a proxy? Something like squid, or are we talking socks?

ftp proxies are actually http.
Assignee: bbaetz → darin
Component: Networking: FTP → Networking: HTTP
QA Contact: benc → tever

Comment 5

17 years ago
No, not one of those personal firewalls.It's a specialized 
(hardware) firewall machine (actually two coupled machines, 
don't know the type, they are not under our auspices), which 
centrally work as a proxy for any type of connection. The 
internal connection port for ftp is 8000 (not 21), maybe 
this causes the problems. Those entries work without problems 
for any other browser and also for earlier Mozilla releases.
I think the problem started with RC3, otherwise we would have 
recognized it immediately.
Hmm. There have been no ftp changes since 1.0 branched, IIRC. Almost certinaly
not since RC1, at least.

Can you attach some packet traces (including contents) between your machine and
an ftp site?
Assignee: darin → bbaetz
Component: Networking: HTTP → Networking: FTP
QA Contact: tever → benc

Comment 7

17 years ago
This problem is definitely not communication-related. If I click on
the file, the browser shows it (if it's something it 
can display), or shows a dialog to 'open with application x'
or 'save file', which works (but often the browser tries to
show the file, even if it is binary garbage; so this is not a
reliable workaround). The popup 'The link cannot be saved because 
either the file does not exist or the link has been removed' does only
popup when clicking on 'save link target as' on the right-click menu,
and it appears immediately (so there's certainly no communication 
involved in that step). But it seems to have something to do with
the proxy entry, as I can download that way from our internal ftp 
I also checked unblocking port 8000 by user pref, but no success
(probably because it's actually not blocked...). I also checked
clearing both caches, no success here also.
I double-checked the proxy entries again, no error there, same as in
netscape (and, as mentioned, worked for nearly a year until recently).
Anybody out there with an equivalent setup ?
IF you attach a packettrace from RC3, and one from a working version of mozilla,
that would be good...

Comment 9

17 years ago
Created attachment 86408 [details]
RC3 packet log

Comment 10

17 years ago
#9 attached is the RC3 packetlog of the communication when only right
clicking and selecting 'save link target as' while trying
to download navigator 4.79 english standalone from 
ftp://ftp.netscape.com. It appears on snoop shortly AFTER
the error message pops up (snoop delay ?).
I hope I find the time to get back a working version to
post another log.
I need the contents of the packet, too. The headers don't help. I don't know the
snoop option to do that, though.

Comment 12

17 years ago
Oh, I see. I cannot do the snoop myself (no root for the Suns), 
I had a hard negotiation with one of the central administrators
to get the trace. I hope I can convince him to give me the contents, too.
If you can't get a trace, then are you in a position to do your own mozilla
build, to turn ftp logging on? (its not on by default in release builds) If you
can test rc1, and see if that works, then that would narrow it down, too.

Comment 14

17 years ago
I can't download any files from an FTP server using Mozilla 1.0 20020530,
including nightly builds. This seems to be a problem restricted to ftp servers,
I have been downloading mp3s off http servers for a while now :-)!

OS: Windows XP 
Reproducible: Always!

Comment 15

17 years ago
With or without a proxy entry ?

Comment 16

17 years ago
Created attachment 87228 [details]
log 1: failing with HTTP:1.1/keepalive/persistent

Here are the requested logs with content:
log-1 shows the answer when trying to download with 'save link target as'
with HTTP1.1, log-2 with HTTP1.0, log-3 a working download with an internal
ftp server (no proxy). Note that the first two ones show a 'protocol error'.
The third one actually downloads a file, but shows a 'SIZE /pub/incoming/
err.ps': command not understood' error.
Hope that helps to quickly identify the problems.

Comment 17

17 years ago
Created attachment 87229 [details]
log-2:failing with HTTP1.0/nokeepalive/nopersistent

Comment 18

17 years ago
Created attachment 87231 [details]
log-3:download from internal server/HTTP1.0/SIZE error
-> file handling. We shouldn't be trying HEAD requests for non http schemes,
even if we're talking to an http server (ie a QI isn't enouhg)

Theres a separate bug on the SIZE error, somewhere, ISTR
Assignee: bbaetz → law
Component: Networking: FTP → File Handling
QA Contact: benc → sairuh
I'll take this...
Assignee: law → bzbarsky
Ever confirmed: true
OS: Solaris → All
Priority: -- → P1
Hardware: Sun → All
Target Milestone: --- → mozilla1.1beta
Created attachment 87834 [details] [diff] [review]
Proposed fix v 1.0
Comment on attachment 87834 [details] [diff] [review]
Proposed fix v 1.0

Attachment #87834 - Flags: review+


17 years ago
Summary: Cannot download files via ftp → [FIX]Cannot download files via ftp

Comment 23

17 years ago
Two questions: 1) Is https always the correct fallback in such  cases ?
               2) Should I report the SIZE error as a separate bug ?
All the patch does is make sure we only use HEAD for "http" and "https" urls. 
It's not a fallback, it's just part of the test.

The SIZE thing is a separate bug, yes. Please check for dups before filing.  ;)

Comment 25

17 years ago
SIZE problem is reported in bug 77033.

Comment 26

17 years ago
Comment on attachment 87834 [details] [diff] [review]
Proposed fix v 1.0

Attachment #87834 - Flags: superreview+
Checked in on trunk.
Last Resolved: 17 years ago
Resolution: --- → FIXED
vrfy'd fixed using 2002.06.18.0x comm trunk bits on linux rh7.2, win2k and mac

Comment 29

17 years ago
Bad ! Now this appears again on Linux with 1.1Beta

1. Goto http://www.dr-rohlfs.de/kettenlehre/
2. click right button and choose 'Save link target as...'
  ==> popup  'Cannot save. ...'

3. click left button on link ==> file appears !

Those are http:// links.  Absolutely nothing to do with this bug.  At all.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.