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

[Ted Keller <ke...@bfg.com>]

Further testing has identified the following data relevant to this bug
report.  First, my first suspicions regarding bwrite are incorrect.  That
routine seems to be operarting properly.

What I determined is the following.

Apache atempts to determine the type of document being retruned to the
client.  On FTP sites, it executes the following set of instructions in
proxy_ftp.c


  1010      else {
  1011      if (r->content_type != NULL) {
  1012          ap_proxy_add_header(resp_hdrs, "Content-Type",
r->content_type,
  1013                   HDR_REP);
  1014          Explain1("FTP: Content-Type set to %s", r->content_type);
  1015      }
  1016      else {
  1017          ap_proxy_add_header(resp_hdrs, "Content-Type",
"image/jpeg", HDR
_REP);
  1018      }


normally, line 1017 is set to text/plain.  For this experiment, I had it
default to image/jpeg.  When set this way, jpeg images are properly
displayed.

This would seem to indicate that some browser implementations then modify
the incoming stream based on the content type.  In my case, netscape 4.05
added the cr characters with the download.  By having apache default to
image/jpeg, netscape behaved better and properly displayed the image.

So now, the problem focuses on why didn't apache properly determine the
content type - and set the headers appropriately.

I will look into that next.  If any of you have good ideas, please direct
my research.

ted keller - bfg.com


On 11 Jul 1998 apbugs@hyperreal.org wrote:

> Thank you very much for your problem report.
> It has the internal identification `mod_proxy/2588'.
> The individual assigned to look at your
> report is: apache. 
> 
> >Category:       mod_proxy
> >Responsible:    apache
> >Synopsis:       ftp proxy adds extra CRs in binary file transfers
> >Arrival-Date:   Fri Jul 10 18:40:00 PDT 1998
>