You are viewing a plain text version of this content. The canonical link for it is here.
Posted to apache-bugdb@apache.org by Ted Keller <ke...@bfg.com> on 1998/07/11 03:30:43 UTC

mod_proxy/2588: ftp proxy adds extra CRs in binary file transfers

>Number:         2588
>Category:       mod_proxy
>Synopsis:       ftp proxy adds extra CRs in binary file transfers
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          sw-bug
>Submitter-Id:   apache
>Arrival-Date:   Fri Jul 10 18:40:00 PDT 1998
>Last-Modified:
>Originator:     keller@bfg.com
>Organization:
apache
>Release:        1.3.0
>Environment:
Irix 5.3 using gcc-2.7.2.3

root@d8544-cs 321: uname -a
IRIX d8544-cs 5.3 11091810 IP7 mips
>Description:
When accessing a ftp site via the ftp proxy and downloading a binary image, the
binary image is coorupted with extra CR characters embeded in the file.

FTP proxy code is patched with LF corrections patches from bug report # 2412 and
additional patches listed in the Jul 1 developers tar file.

Accessing the file direct (without apache ftp proxy) the file is of total length
6118 bytes

Accessing the file using the apache ftp proxy, the file increases to 61345 bytes.

Dumping the file (od -x) I noted the following character string differences

File without proxy ....

120c 0b0a 0a0b 1710

File with proxy .....

120c 0b0d 0a0d 0a0b 1710

Note the extra 0d characters inserted into the file.
>How-To-Repeat:
Random example url


ftp://ftp.sunet.se/pub/pictures/people/faces/angel.gif
>Fix:
Suspect strongly that the problem lies in bwrite (main/buff.c).  That routine
always attempts to add CRLF to the end of each buffer write.  This is called from
ap_proxy_send_fb which is called from proxy_ftp.c.

The problem, I believe, originates in ap_proxy_send_fb (called from proxy_ftp
when it start to pump data from the incomming connection and sends it both to 
the cache and the output connection. (see lines 466-490).

ap_proxy_send_fb calls ap_bwrite - once for the cache output and a second time
to transmit the data to the client.  ap_bwrite then calls the bwrite routing which 
I suspect is doing the real damage.

The concept of adding CR/LF should be examined to ensure it is correct. 

These should be binary transfers - no special processing required (other than the
desired buffering for the cache files).
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]