DO NOT REPLY [Bug 14976] New: - ProxyPass segfault on ftp:// urls

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=14976>. 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=14976

ProxyPass segfault on ftp:// urls

           Summary: ProxyPass segfault on ftp:// urls
           Product: Apache httpd-1.3
           Version: 1.3.26
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: mod_proxy
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: unreal@fly.srk.fer.hr

This seems to be an old bug, I've found references to it at least as way back as 1.3.9 (see http://bugs.debian.org/cgi-bin/bugreport.cgi? archive=no&bug=57316) but a quick search through the apache bug database gave no hits. I've tried various versions of Apache ranging from 1.3.22 to 1.3.26 and all show the same behaviour, I don't have a 1.3.27 handy but the changelog made no mention of this bug, so I assume it's not fixed.

Anyway, the problem is that trying to use Apache as a reverse proxy to an FTP site, using something like:

RewriteRule ^/redhat/(.*)$ ftp://ftp.redhat.com/pub/$1 [P]

or

ProxyPass /redhat/ ftp://ftp.redhat.com/

causes the http process to sigsegv when trying to access the URL. The log shows:

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related httpd.apache.org Links announce bugs cvs dev docs gui-dev modproxy-dev packagers testers Request more information about Pantek

[notice] child pid 32369 exit signal Segmentation fault (11)

Using an http:// URL as the target works fine, naturally. I've seen no difference whether mod_proxy is compiled into the httpd binary or loaded as module at startup.