>Number: 2412
>Category: mod_proxy
>Synopsis: proxy_ftp inserts a spurious new line in HTTP headers,
>corrupting further output
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apache
>State: open
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Thu Jun 11 06:10:00 PDT 1998
>Last-Modified:
>Originator: [EMAIL PROTECTED]
>Organization:
apache
>Release: 1.3.0
>Environment:
OS is Debian with custom kernel (Linux yelm 2.0.34 #3 Tue Jun 9 22:05:47 PDT
1998 i586 unknown).
Compiler is egcs-1.0.3 prerelease.
>Description:
If proxy_ftp.c(ap_proxy_ftp_handler) gets a SIZE response, the newline in
the response is not stripped. This results in a spurious newline being
inserted after the Content-Length HTTP header. This in turn causes
subsequent headers to be interpreted as data instead of headers.
>How-To-Repeat:
Problem occurs when caching the any FTP response with a size header.
I first noticed the problem when fetching URLs like
ftp://ftp.fuller.edu/debian/dists/unstable/contrib/binary-i386/Packages.gz
>Fix:
In ap_proxy_ftp_handler, add the following lines
--- /tmp/apache_1.3.0/src/modules/proxy/proxy_ftp.c Wed May 27 15:56:05 1998
+++ ./proxy_ftp.c Thu Jun 11 05:35:39 1998
@@ -905,6 +905,15 @@
ap_bflush(f);
Explain1("FTP: SIZE %s", path);
i = ftp_getrc_msg(f, resp, resplen);
+
+ if (i == 213) { /* Size command ok. */
+ /* If the size response ends in a linefeed, we have to
+ * get rid of it. */
+ const size_t resp_strlen = strlen(resp);
+ if (resp[resp_strlen - 1] == '\n')
+ resp[resp_strlen - 1] = '\0';
+ }
+
Explain2("FTP: returned status %d with response %s", i, resp);
if (i != 500) { /* Size command not recognized */
if (i == 550) { /* Not a regular file */
========================================================================
These lines were inserted here so that the new line is stripped
before possibly being printed by the Explain2 statement.
Otherwise, it would make more sense to move the lines down to
join the lines in the other "Size command ok" section about
thirty lines later.
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <[EMAIL PROTECTED]> in the Cc line ]
[and leave the subject line UNCHANGED. This is not done]
[automatically because of the potential for mail loops. ]
