Closed
Bug 148813
Opened 23 years ago
Closed 23 years ago
[FIX]Cannot download files via ftp
Categories
(Core Graveyard :: File Handling, defect, P1)
Core Graveyard
File Handling
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.1beta
People
(Reporter: beanladen, Assigned: bzbarsky)
References
()
Details
Attachments
(5 files)
15.62 KB,
application/octet-stream
|
Details | |
22.61 KB,
text/plain
|
Details | |
22.48 KB,
text/plain
|
Details | |
28.24 KB,
text/plain
|
Details | |
1.30 KB,
patch
|
bbaetz
:
review+
darin.moz
:
superreview+
|
Details | Diff | Splinter Review |
RC3/Sun Sparc/Solaris 8/PatchCluster 1/FTP over proxy
Mozilla cannot download any file via ftp !
Demonstration:
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...'
Expected:
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•23 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
TYPE I
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•23 years ago
|
||
The problem appears to be a problem with *one* of the round robin
servers for ftp.hp.com (192.6.234.9) which has /pub/index.html marked as
a directory, whereas on the other 6 it is a file.
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)
Comment 4•23 years ago
|
||
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
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.
Comment 6•23 years ago
|
||
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
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
server.
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 ?
Comment 8•23 years ago
|
||
IF you attach a packettrace from RC3, and one from a working version of mozilla,
that would be good...
Reporter | ||
Comment 10•23 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.
Comment 11•23 years ago
|
||
I need the contents of the packet, too. The headers don't help. I don't know the
snoop option to do that, though.
Reporter | ||
Comment 12•23 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.
Comment 13•23 years ago
|
||
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•23 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!
Reporter | ||
Comment 15•23 years ago
|
||
With or without a proxy entry ?
Reporter | ||
Comment 16•23 years ago
|
||
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.
Reporter | ||
Comment 17•23 years ago
|
||
Reporter | ||
Comment 18•23 years ago
|
||
Comment 19•23 years ago
|
||
-> 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
Assignee | ||
Comment 20•23 years ago
|
||
I'll take this...
Assignee: law → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Solaris → All
Priority: -- → P1
Hardware: Sun → All
Target Milestone: --- → mozilla1.1beta
Assignee | ||
Comment 21•23 years ago
|
||
Comment 22•23 years ago
|
||
Comment on attachment 87834 [details] [diff] [review]
Proposed fix v 1.0
r=bbaetz
Attachment #87834 -
Flags: review+
Assignee | ||
Updated•23 years ago
|
Summary: Cannot download files via ftp → [FIX]Cannot download files via ftp
Reporter | ||
Comment 23•23 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 ?
Assignee | ||
Comment 24•23 years ago
|
||
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. ;)
Reporter | ||
Comment 25•23 years ago
|
||
SIZE problem is reported in bug 77033.
Comment 26•23 years ago
|
||
Comment on attachment 87834 [details] [diff] [review]
Proposed fix v 1.0
sr=darin
Attachment #87834 -
Flags: superreview+
Assignee | ||
Comment 27•23 years ago
|
||
Checked in on trunk.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 28•23 years ago
|
||
vrfy'd fixed using 2002.06.18.0x comm trunk bits on linux rh7.2, win2k and mac
10.1.5.
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 29•23 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 !
REOPENING !
Assignee | ||
Comment 30•23 years ago
|
||
Those are http:// links. Absolutely nothing to do with this bug. At all.
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•