Closed Bug 168093 Opened 22 years ago Closed 21 years ago

Connecting to GuildFTPserver, get "425 Download failed" error message

Categories

(Core Graveyard :: Networking: FTP, defect)

Product:
Core Graveyard
Component:
Networking: FTP
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: CatamountJack, Assigned: dougt)

Details

I set up an FTP server (GuildFTP 0.999.5) on my computer to use to remotely
store (publish) my Mozilla Calendar files on.  It doesn't work.  When trying to
publish the file I get the alert message:

[Exception... "Component returned failure code; 0x804b000a [nsIURI.spec]"
nsresult: "0x804b000a (<unknown>) location: "JS frame ::
chrome://calendar/content/calendarPublish.js :: create_channel_from_url :: line
199" data: no]

So I tried logging into my server using  ftp://###.###.###.###/ in the browser
and I will get the message "425 Download failed".  When logging in using: 
ftp://Username@###.###.###.###/ I will then get a password prompt (as I should)
but once I enter the password, I get the same "425 Download failed" message. 
GuildFTP itself shows "Unknown error" under the "Downloads" tab for the "Past
Connections" tab.

I am not trying to download anything, simply log into the server.  I have been
able to access the site using both SmartFTP FTP client and Internet Explorer
(using the same URLs as above) without problems.
reporter (Brett): can you reproduce this bug with a recent build of mozilla (for
example, 1.2.1)? if so, please comment again with details. if not, please
resolve this bug as WORKSFORME. thanks.

No response from reporter for >30 days. resolving WORKSFORME.

Reporter: If you can reproduce this with a recent build of Mozilla, then please
reopen this bug and give details. Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
reopen, to go to invalid.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Summary: Connecting to FTP server, get "425 Download failed" error message → Connecting to GuildFTPserver, get "425 Download failed" error message
resolved/invalid.

Brett: if you have more information, please reopen!
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → INVALID
I apologize for not having checked this bug in so long, I had given up on trying
to make it work so I forgot about it after a bit.  

Using today's nightly build (2003011908) I tried logging into the server again
but still get the same errors/response on both ends.  This is a different (new)
machine from what I was running before and the server is now GuildFTPd 0.999.6.
 I take it nobody else found the same issue?  I don't know what more information
I can provide but if you have specific questions I will do my best to answer
them.  Thank you.

Reopening...
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
I have this bug too, confirmed with Mozilla version 1.1, 1.3 and 1.4rc3.
For more details (ftp protocol etc.) see my discussion in the forum of
GuildFTPd: http://www.guildftpd.com/phpBB2/viewtopic.php?p=5816

Also this bug appears when you try ftp://ftp.sun.org
All ftp requests work with Netscape Navigator 4.7 and IE 5.5 and IE 6.0

Thanks for looking at again ;-)
Sorry - wrong link - it's ftp://ftp.sun.com
I can reproduce this bug using the Moz1.4rc3 as well as the latest nightly Firebird.

marking this bug -> NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
When mozilla issues RETR for /, the GuildFTPServer responds with a 150.  A 150
means that the file status is okay, that is, a file does exist for /.  The
server then fails to send any data for this request.

I could create a work around in the mozilla so that any request for a directory
(a URL either trailing in a / or has no url path part), immediately issues a
LIST command instead of the the RETR sequence.  However, doing so will break
RETR directory requests that return tar.gz content.  (I am in favor of breaking
this tar.gz "feature" because i can futher reduce the number of round trip
requests that the client has to make to get LIST content).

However before doing something that drastic, i would like to know why the
GuildFTPServer returns a 150.


I don't understand the details exactly, but what's about the sun page
ftp://ftp.sun.com ? Does sun use the GuildFTPd too?

When I try ftp://ftp.mozilla.org with mozilla I get the directoy listing only,
but using Netscape Navigator 4.73 I get a welcome message like
""
################################################

Welcome to ftp.mozilla.org!
""
etc. etc. up to "Contact webmaster@mozilla.org with any problems. 25" and after
that the directory listing. Where is that message when I use Mozilla?

I already noticed that behaviour when using "Personal FTP Server 4.46" as the
ftp server on my localhost and then try ftp://127.0.0.1 with both, Mozilla and
Netscape 4.73: Mozilla only shows the directory, Netscape 4.73 the welcome
message and some comments too.

Maybe these additional informations may help. Thanx for your good work with Mozilla!
> I don't understand the details exactly, but what's about the sun page
ftp://ftp.sun.com ? Does sun use the GuildFTPd too?

The sun page has nothing to do with this bug.  I seriously doubt that Sun uses
GuildFTPd.

>When I try ftp://ftp.mozilla.org with mozilla I get the directoy listing only,
but using Netscape Navigator 4.73 I get a welcome message like

Different bug.
------- Additional Comment #9 From Doug T 2003-07-01 10:49 ------- 
When mozilla issues RETR for /, the GuildFTPServer responds with a 150.  A 150
means that the file status is okay, that is, a file does exist for /.  The
server then fails to send any data for this request.

That sure is funny, how did you manage to get it to reply that?
I just used FlashFXP (www.flashfxp.com) to test it, here is how I did:
Connect to GuildFTPd version .999.9 and manually sent "RETR /"
and GFTPd replied:
[17:06:24] RETR /
[17:06:24] 425 Permission Denied.
Just as it should

But Im really curious why your product is sending RETR instead of REST, why 
dont you follow the standard RFC ?

_______
Regards
jesper@nitrolic.com
co'owner of GuildFTPd
Ok I have figured out why GFTPd behaives like this.
It comes down to that users of the server has READ access on the root 
directory. then GFTPd replies:

[18:10:12] RETR /
[18:10:12] 150 Opening ascii mode data connection for / (0 bytes).
[18:10:13] 425 Download failed.

it all comes down to misconfigured servers! 
but still Mozilla should send REST and LIST and not RETR!
as i said in comment #9, we first issue a RETR since we have no idea if the
request is for a file or directory.  Some FTP servers actually send tar.gz when
a RETR is sent for a directory listing.

I do not understand why we would send a REST for any reason in this case. 
Please elaborate.

Also, i have been thinking about treating empty url paths and path with a
trailing slash as alway a LIST request.  This would allow FTP to shortcut some
of the steps in listing a directory.

[quote]------- Additional Comment #14 From Doug T 2003-07-04 09:26 -------

I do not understand why we would send a REST for any reason in this case. 
Please elaborate.[/quote]

Cause proper RFC sends "REST" then "LIST -is", its not like you want to start 
download then entire FTPtree before you have even logged in, right ?
as I mention somewhere in this 
post :http://www.guildftpd.com/phpBB2/viewtopic.php?p=5816, you can look at 
FlashFXP or IE vs BPFTPd

eg. BulletProof has a fix added for your immediate RETR,, some others may have 
too but we dont, in any case youre not using proper RFC.
(we will fix it for our 1.0 release (maybe before)). but still you should fix 
Mozilla to use the proper RFC.

The problem comes down to our users has READ attrib on their root folder, 
which GuildFTPd isnt designed to, as we designed it to work with virtual paths 
and not locals. however both works, (except for Mozilla)

But thanks to you, I have found a work around for our users, I say many 
thanks :) and I am looking forward to future development between your client 
vs our server, if you ever encounters any issues, then mail me ASAP.

Regards
jesper@nitrolic.com
co'owner of GuildFTPd


Jesper, which part of rfc959 tells you that the state should go from REST to LIST? 

Do you have any comment about treating ftp URL's ending in a trailing slash as a
LIST request?
its doesnt say go from REST to LIST, it was just saying that it should be REST 
then LIST and not RETR then LIST :)

About the / as a list command:
That would be a good idea I think.
InternetExplorer adds the / it self if you dont make it, so Mozilla could 
too :)
FTP://127.0.0.1 or FTP://127.0.0.1/ should be the same I would say.
> its doesnt say go from REST to LIST, it was just saying that it should be REST 
then LIST and not RETR then LIST :)

RFC 959 states this? I did not read that anywhere.  

Thanks for your input.
Any other FTP client I have ever seen uses REST during login.
Just load up any to try ;)
There is simply no reason to use "RETR /" unless the server allows you to 
download the root, which none does :P

USER Jesper
331 User name okay, Need password.
PASS (hidden)
230 User logged in.
SYST
215 UNIX Type: L8 Server
REST 100
350 Restarting at byte offset 100. 
REST 0
350 Restarting at byte offset 0.
PWD
257 "/" is current directory.
TYPE A
200 Type set to A.
PORT 127,0,0,1,17,163
200 PORT command successful.
LIST -al
150 Opening ASCII mode data connection for /bin/ls (529 bytes).
226 Transfer successful.

"because all of the FTP servers do" != "what the RFC says".  This fact is the
trouble with all FTP implementations. :-)

some servers years ago did send back tar/gz format for directory requests.

Just cause it doesnt say use REST doesnt mean they want you to use RETR :P
I am pretty sure that if RFC959 had an example, then they wouldnt use RETR on 
login ;)
You can also choose not to use any of them, like IE does :)
REST is just telling you that if the server supports Resume/Append, as some 
servers replies "resume is not supported" if APPE/REST is disabled.

>REST 100
>500 Download resuming is disabled on this server.
>This site may not allow file resuming

We have added a fix for Mozilla users.
We have simply added that when an RETR event ends trailing slash
then the server will reply with 550 Permission Denied, You use Mozilla ;)
e.g.
>RETR /
>RETR /Jesper/
550 Permission Denied

Watch www.GuildFTPd.com for a new release today/tomorrow :)

REST is definately not required, unlesss you're RESTarting a download. Mozilla
doesn't do that yet (well, the backend does, but noone ever wrote the frontend
for that)

Every other FTP server manages - its a guildftp bug unless you can quote RFC
language to say otherwise (And the FTP RFCs aren't the world's best, either).
------- Additional Comment #23 From Bradley Baetz 2003-07-08 13:58 ------- 
REST is definately not required, unlesss you're RESTarting a download. Mozilla
doesn't do that yet (well, the backend does, but noone ever wrote the frontend
for that)

Every other FTP server manages - its a guildftp bug unless you can quote RFC
language to say otherwise (And the FTP RFCs aren't the world's best, either).
--------

REST is sent on login, to find out if the server allows RESUME/RESTart, else 
its not used for anything else in the login sequence ;)

Every other FTPd manages what? Even simple BPFTPd doesnt like "RETR /", which 
makes me thing they added the same thing we did, they just did it before we 
did :P

And if you can find in RFC959 that RETR is a part of the login sequence, I 
would be happy to know the §# :)
And also if it was a bug in GFTPd, then why is it only affecting Mozilla ?:P 
heheh
Its not part of the login sequence. Nothing beyond a successful reply to a PASS
is part of the login sequence.

Yes, the reason clients send REST is to determine if resuming is supported. That
doesn't imply that clients should send it, and in fact theres no point to us
doing so because we don't resume anyway.

Anyway, if you change it so that you error out on the RETR, it should be fine.
Webbrowsers are different than ftp clients in that 'go to this directory' and
'get this file' are the same UI. Command line clients have 'cd' vs 'get'.
Marking wontfix.  Vender has workaround.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → WONTFIX
?
Wow - that's what I expected to solve the other point of my comment #10:

> When I try ftp://ftp.mozilla.org with mozilla I get the directoy listing only,
> but using Netscape Navigator 4.73 I get a welcome message like
> ""
> ################################################
> 
> Welcome to ftp.mozilla.org!
> ""
> etc. etc. up to "Contact webmaster@mozilla.org with any problems. 25" and > after
> that the directory listing. Where is that message when I use Mozilla?

Zora
I dont understand why Mozilla int being fixed... so that future ftp daemons 
dont have to fight along with it....
comment 10 is an orthogonal problem.  if you want to see ftp welcome messages,
file an RFE or better yet, send me a working patch.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.