15.62 KB, application/octet-stream
22.61 KB, text/plain
22.48 KB, text/plain
28.24 KB, text/plain
1.30 KB, patch
Darin Fisher: 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 !
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.
The problem appears to be a problem with *one* of the round robin servers for ftp.hp.com (188.8.131.52) 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)
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.
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 ?
IF you attach a packettrace from RC3, and one from a working version of mozilla, that would be good...
#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.
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.
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!
With or without a proxy entry ?
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.
-> 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
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Solaris → All
Priority: -- → P1
Hardware: Sun → All
Target Milestone: --- → mozilla1.1beta
Comment on attachment 87834 [details] [diff] [review] Proposed fix v 1.0 r=bbaetz
Attachment #87834 - Flags: review+
16 years ago
Summary: Cannot download files via ftp → [FIX]Cannot download files via ftp
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. ;)
SIZE problem is reported in bug 77033.
Comment on attachment 87834 [details] [diff] [review] Proposed fix v 1.0 sr=darin
Attachment #87834 - Flags: superreview+
Checked in on trunk.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
vrfy'd fixed using 2002.06.18.0x comm trunk bits on linux rh7.2, win2k and mac 10.1.5.
Status: RESOLVED → VERIFIED
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 !
Those are http:// links. Absolutely nothing to do with this bug. At all.
You need to log in before you can comment on or make changes to this bug.