DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16556>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16556 mod_proxy malfunctions with ftp:// URLs Summary: mod_proxy malfunctions with ftp:// URLs Product: Apache httpd-1.3 Version: 1.3.27 Platform: PC OS/Version: FreeBSD Status: NEW Severity: Major Priority: Other Component: mod_proxy AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] I found what I believe to be a couple of problems with mod_proxy and ftp:// URLs: (1) When mod_proxy attempts to retrieve a file by FTP it fails to explicitly set an ASCII/binary transfer type when it sends an FTP SIZE command. Some FTP servers (such as the FreeBSD ftpd) report back different file sizes depending on the current transfer mode. mod_proxy DOES explicitly set an ASCII/binary transfer type before issuing the FTP RETR command, but if this explicit transfer mode differs from the assumed one that FTP SIZE used then there is a mismatch between expected file size and actual file size. I'd recommend explicitly setting the file transfer type before issuing the FTP SIZE, the same way the FTP RETR does. (2) In the ftp_set_TYPE() function there appears to be some undesirable "memory" across FTP file retrievals. The ftp_set_TYPE() function attempts an optimization using the static local variable "old_type" to remember the current transfer mode. If the newly requested mode doesn't differ from the current mode then ftp_set_TYPE() doesn't bother to send an FTP TYPE command because it would be unnecessary. I think this causes a problem. It appears that this static local variable is not being reset when it needs to be. I have done some tests where I repeatedly requested an ftp:// file through mod_proxy (both with the default binary transfer mode and an explicit ";type=i" URL) and for some unknown reason the file sometimes comes across in binary and sometimes comes across in ASCII, even if I explicitly use a ";type=i" URL! I narrowed the problem down to this static old_type variable. If I remove its function and always send an FTP TYPE command in ftp_set_TYPE() then files are predictably retrieved the way they should be. Perhaps the static nature of old_type causes it to be remembered across retrievals done by a particular httpd child process? Maybe the first time an FTP retrieval comes in to an Apache child the file will be correctly transferred in binary mode, but when that same child handles another retrieval it will mistakenly think it's still in binary mode (and thus never resend the "TYPE I" command) and accidentally retrieve the file in ASCII mode? From watching the FTP session in tcpdump where a file is mistransferred I noticed that httpd never once sends an FTP TYPE command, which leads me to believe that ftp_set_TYPE() mistakenly optimized it away based on false memory of the transfer mode. I have prepared patches to Apache 1.3.27 that fix these issues and placed them here: http://www.uniserver.com/apache.proxy.ftp.problem.diff Feel free to review them an integrate them (or your own versions) into the source tree. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
