User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 I have an ftp server running on a network appliance. It's none of the "standard" ftp server, runs on an special OS, and therefore its presentation (reply 215 "xxxx" to SYST command) cannot be know to Mozilla developers. But it's an rfc compliant ftp server. In my opinion if the ftp server is none of the known ones Mozilla should anyway accept to proceed, assuming it's rfc standard, while actually it stops with a dialog box telling "FTP server 215 xxxx currently unsupported". I cannot provide now a url reacheable from internet, I also don't think you need it, but eventually I can arrange something. Btw. Konqueror and Gftp are ok, while Opera has other problems on authentication (to be investigated). On Win, IE is ok (I've not tried yet Mozilla and Opera). Reproducible: Always Steps to Reproduce: 1.Patch an ftp server so that it answers something "unexpected" to SYST command, e.g. 215 Newcomer OS rel 0.1 ;-), and connect from Mozilla 2.Alternatively contact me and I'll arrange the ftp server reacheable from the internet for a short test Actual Results: Dialog box telling "FTP server 215 xxxx" currently unsupported", I click on OK and ftp connection is closed. Expected Results: Proceed assuming it's dealing with an rfc compliant ftp server

Not a blocker. Can you provide details on the FTP server and/or a network trace ? set NSPR_LOG_MODULES=nsSocketTransport:5,nsFTPProtocol:5 set NSPR_LOG_FILE=c:\mozftp.log related: bug 95590.

The reason for this : There is no standard for ftp dir listings and Mozilla can't parse an unkown FTP server. Does it follow other FTp servers listings that we could add your Syst response in the Mozilla code ? The error message is from bug 84472... confirming as enhancement (supporting your FTP server)

The FTP server is a "own" development that runs on embedded RTOS. Upon reception of the command SYST it answers "215 CPX generation: 1", or "215 CPX generation: 2". I guess you gave me instructions for tracing under Win, but I'm testing on Linux. This is my first bug report, be patient, what shall I do to make the traces you request?

no trace needed because the Mozilla should abort after the syst. Reporter: Does it follow a known directory listing (such as Unix, BSD ..) ?

The ftp server follows the common unix directory listing used by the most common unix ftp server we could check on the internet. I discussed this issue with my collegues and we decided to change the reply to SYST command in: 215 UNIX Type: L8 Version: CPX This solves the problem and actually it does not lie because the output is really the same of Unix. I thank all of you for your help, but I'm still persuaded that you should improve this section of Mozilla. The idea of the self-learning parser I read in related bug 95590 is very attractive. Until you have to rely on the SYST response I suggest that you treat unknown syst as "UNIX", may be with the dialog box that informs "Unknown ftp server type, assuming UNIX layout, visualisation may be corrupted" (or something similar).

There are all really good suggestions, but the reality is that there just don't seem to be many "foreign" server types out there any more, especially on the public network. Many once-exotic sites seem to have been replaced with, not surprisingly, Linux-based servers.

Speaking about "internet sites" I agree with your view, in your position I would probably make the same consideration. The situation may be different for "appliances" where a small ftp server may be needed but OS is none of the major ones. Still I would at least leave the possibility to "go on" even if the reply to SYST is for an unknown ftp server, may be with a warning that it will be threated as unix. If one is forced to develop a own ftp, as in our case, it's highly probably that he will copy Linux behaviour, simply because sources are available.

Re: comment #2: The ftp dir listing parser does not depend on the results from SYST. In fact, it doesn't even see the results from SYST. The SYST is only necessary for two things: 1) Are directory names VMSish? (see bug #22299). 2) Does the server need NSLT instead of LIST? (not done by Moz). The FTP_xxx_TYPE (where xxx is GENERIC,UNIX,VMS,NT,OS2) defines in nsFtpConnectionThread.h are completely obsolete, and with the exception of FTP_VMS_TYPE unused. The code that is causing this bug (#202730) and bug 204007 is in nsFtpConnectionThread.cpp lines 1218-1248. They are remnants from a time before the smart LIST parser and need to vanish. In fact, all but three lines (1213-1215) of R_syst is obsolete.

*** Bug 204007 has been marked as a duplicate of this bug. ***

Removes all uneccessary/obsolete crud from R_syst

dougt: do you want to take this patch?

mass reassigning to nobody.

(In reply to comment #6) > There are all really good suggestions, but the reality is that there just don't > seem to be many "foreign" server types out there any more, especially on the > public network. Many once-exotic sites seem to have been replaced with, not > surprisingly, Linux-based servers. We, es-ES translation team, have received a support request in our website contact form from a mexican citizen that has problems accessing a government website: http://www.sat.gob.mx/nuevo.html If you click on the left sidebar option "Software y formas fiscales" (Fiscal Software and Forms) and "Descarga de programas" (Programs download), and then in the main content block you follow the second link "Declaración informativa de operaciones con terceros (DIOT) 2007 Simplificada" (or a similar one if this comment is reviewed in the future and the link has changed), you'll get a bunch of links to a FTP server which is (mis?)configured to report "XXXXXXXXXXXXXXXXXX" as system type, despite being a Microsoft FTP service. Neither Firefox 2.x nor SeaMonkey 1.1.x can download the files. Other browsers (IE7 per user comments, and Opera on Linux tested by myself) work OK; even the FireFTP extension can successfully download the file. The problem lies around: http://lxr.mozilla.org/mozilla1.8/source/netwerk/protocol/ftp/src/nsFtpConnectionThread.cpp#1302

This same error is seen when we attempt to download images from opensuse.org. In particular, try this mirror: ftp://suse.mirrors.tds.net/pub/opensuse/distribution/10.3/repo/oss/ and you get "The FTP server 215 XXXXXXXXXXXXX is currently unsupported." Change that URL from "ftp:" to "http:" and you get a directory listing. You would think the server is running OpenSuSE of some sort ;-) We obtain the error with both Firefox 2.2 and 3.0b2.

I've tested Cyrus Patel's patch on nsFtpState::R_syst() on Linux and it does solve the issue on ftp://ftp2.sat.gob.mx as reported on comment #13 (which I have to use on almost a daily basis), no unwanted effects on other ftp sites. Can any one else verify this? Thanks in advance.

CCing Doug so he actually sees this.

Regarding Mexico's Tax Authority (SAT), ftp site, here is the output from Filezilla, with Windows XP SP3. It seems thay are explicitly masking the 215 response, but the signature is a MIcrosoft FTP Server 5.0 I will try to make a custom Firefox build for Windows with Cyrus's patch and test it. I've done it before during Firefox 2.0x time, so I don't expect that many problems if I can build with an VC Express edition. Note.- I added the HELP command at the end ---- ftp://ftp2.sat.gob.mx/agti_servicio_ftp/verifica_comprobante_ftp/ Status: Resolving address of ftp2.sat.gob.mx Status: Connecting to 200.33.74.102:21... Status: Connection established, waiting for welcome message... Response: 220 satcpanftp01 Microsoft FTP Service (Version 5.0). Command: USER anonymous Response: 331 Anonymous access allowed, send identity (e-mail name) as password. Command: PASS ************** Response: 230 Anonymous user logged in. Command: SYST Response: 215 XXXXXXXXXXXXXXXXXXXXXX Command: FEAT Response: 500 'FEAT': command not understood Status: Connected Status: Retrieving directory listing... Command: CWD /agti_servicio_ftp/verifica_comprobante_ftp Response: 250 CWD command successful. Command: PWD Response: 257 "/agti_servicio_ftp/verifica_comprobante_ftp" is current directory. Command: TYPE I Response: 200 Type set to I. Command: PASV Response: 227 Entering Passive Mode (200,33,74,102,17,99) Command: LIST Response: 125 Data connection already open; Transfer starting. Response: 226 Transfer complete. Status: Directory listing successful Command: help Response: 214-The following commands are recognized(* ==>'s unimplemented). Response: ABOR Response: ACCT Response: ALLO Response: APPE Response: CDUP Response: CWD Response: DELE Response: HELP Response: LIST Response: MDTM Response: MKD Response: MODE Response: NLST Response: NOOP Response: PASS Response: PASV Response: PORT Response: PWD Response: QUIT Response: REIN Response: REST Response: RETR Response: RMD Response: RNFR Response: RNTO Response: SITE Response: SIZE Response: SMNT Response: STAT Response: STOR Response: STOU Response: STRU Response: SYST Response: TYPE Response: USER Response: XCUP Response: XCWD Response: XMKD Response: XPWD Response: XRMD Response: 214 HELP command successful.

Comment on attachment 127811 [details] Drop-in replacement for nsFtpState::R_syst() Cyrus' comment #8 is still correct: the only server type that we're actually using is FTP_VMS_TYPE. Assuming the smart LIST parser will correctly handle any nonconformant FTP server that exists (or emerges), the logic here should work. But: 1) this file isn't a patch. 2) if we're going to use mServerType only to flag VMS, we might as well change the name to 'mIsVMSServer' and make it a boolean flag. 3) I'm not clear that anyone has really tested or examined what will happen if we remove the "unrecognized FTP server" check. We need to make sure we fail gracefully (and hopefully informatively) for an FTP server that the smart LIST doesn't recognize. We also either want a test, or if that's not possible, at least manual testing on a wide range of FTP servers (i.e. the types handled in ParseFTPList).

What's the current status of this bug? The Mexico’s ftp server is WFM. In behalf of bug 157531, I'm about to add a new error code to catch the "unrecognized SYST response" error, to show it as an error page instead of dialog. >+/** >+ * This is a kind of client error. This error indicates that necko fails to >+ * parse SYST command's response, and that necko has no idea what the server's >+ * system is. In this case, we give up using this FTP server to prevent crash. >+ * For example, a crash due to parsing a strangely formatted files list, which >+ * looks like neither "ls", "DIR" nor anything we know. See bug 84472. >+ */ >+#define NS_ERROR_FTP_UNSUPPORTED \ >+ NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_NETWORK, 29) If |R_syst()| will cease to return |FTP_ERROR|, we don't need the error page for this error. I'm relatively conservative about this bug. However, the error page contains more or less l10n strings and definitely I don't want to change them frequently. So I'd like to know whether or not someone is still working on this issue and whether or not this bug is going to be fixed. (In reply to Jason Duell (:jduell) from comment #18) > We also either want a test, or if that's not possible, at least manual > testing on a > wide range of FTP servers (i.e. the types handled in ParseFTPList). Probably automated test do not work for this bug. That's why, I guess, the source code has a long list of ftp servers. http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/ftp/test/frametest/index.html Maybe we can add ftp://ftp2.sat.gob.mx/ to it...

No one's working on this now--feel free to take it if you want.

> if you want. Not really, though removing l10n strings is very attractive to me. I'm afraid this bug is so regression risky that this bug's patch should be always ready to back-out. In the end, we need the error page, however short its lifetime may be.

i'd really hope that if anyone was interested in FTP improvements, they'd consider replacing our C++ implementation with fireftp.

only critical ftp changes in core now