DO NOT REPLY [Bug 16556] New: - mod_proxy malfunctions with ftp:// URLs

[bu...@apache.org]

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: bugs@httpd.apache.org
        ReportedBy: apache@uniserver.com


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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org