Bug#191930: apache-common: mod_proxy breaks on pages with blank Reason-Phrase
Package: apache-common
Version: 1.3.26-1.1
Severity: normal
Tags: upstream patch
On pages with status lines that have an empty Reason-Phrase (that is,
pages whose status line is simply "HTTP/1.1 200 " or similar),
mod_proxy will insert an extra blank line between the HTTP status line
and the headers.
For example, here is the view of a simple cgi script through a broken
proxy - I pipe the output through cat -vte to show what's going on.
First, using no proxy:
cush:/$ nc cush 80 | cat -vte
GET /cgi-bin/nph-t HTTP/1.1
Host: cush
HTTP/1.1 200 $
Date: Sun May 4 20:27:46 EDT 2003$
Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_perl/1.26 mod_jk/1.1.0$
Connection: close$
Content-type: text/html$
$
<html><head><title>mytitle</title></head><body><p>Test.</p></body></html>$
Now, using a broken proxy:
cush:/$ nc cush 80 | cat -vte
GET http://localhost/cgi-bin/nph-t HTTP/1.1
Host: localhost
HTTP/1.1 200 $
^M$
Date: Mon, 05 May 2003 00:33:12 GMT^M$
Server: Apache/1.3.26 (Unix) Debian GNU/Linux mod_perl/1.26 mod_jk/1.1.0^M$
Content-type: text/html; charset=iso-8859-1^M$
X-Cache: MISS from www.martinhouse.internal^M$
Transfer-Encoding: chunked^M$
^M$
4a ^M$
<html><head><title>mytitle</title></head><body><p>Test.</p></body></html>$
^M$
0^M$
^M$
The end result of this is that browsers looking through a mod_proxy
proxy end up seeing the html source and headers instead of the
properly rendered HTML. It gets worse when the response is supposed
to be a redirection of some kind. (For example, visit
http://www.crosswire.org/sword/ in a browser while looking through a
mod_proxy cache)
This problem comes from a bug in proxy_util.c, in the function
ap_proxy_read_response_line - the problem is that ap_getline leaves
the buffer looking like this:
'H' 'T' 'T' 'P' '/' '1' '.' '1' ' ' '2' '0' '0' '\0' '\n' '\0' <other>
Where <other> is trailing garbage we don't care about.
Anyway, ap_getline leaves the buffer in this state because it trims
all trailing whitespace. Then, around line 1610 of proxy_util.c, the
code does some short sighted (and, I believe, unnecessary)
manipulations which leave the buffer as:
'H' 'T' 'T' 'P' '/' '1' '.' '1' ' ' '2' '0' '0' ' ' '\n' '\0' <other>
This leads to the problem above.
Anyway, the fix is pretty simple: just drop the following patch in
debian/patches:
--- build-tree/apache_1.3.26/src/modules/proxy/proxy_util.c
+++ build-tree/apache_1.3.26/src/modules/proxy/proxy_util.c
@@ -1607,6 +1607,9 @@
}
*backasswards = 0;
+ /* Fix for the case when the remote Reason-Phrase (RFC2616) is empty
+ * In that case, ap_getline trims the space after the status code */
+ if ('\0' == buffer[12]) buffer[13] = '\0';
buffer[12] = '\0';
r->status = atoi(&buffer[9]);
buffer[12] = ' ';
This will ensure that mod_proxy emits an RFC-conformant status line
(the space after the status number is required), and removes the extra
blank line. Another fix that works on Debian systems is to remove the
two lines that manipulate buffer[12], but I suspect that they're there
to deal with some odd atoi implementations on one of the myriad
machines apache compiles on.
Upstream has a bug (number 10052) in their bugzilla which is another
manifestation of this same bug. However, the patch attached to that
bug doesn't really address the cause of the problem as much as the
symptom. Also, the bug has been held in status "NEW" for over six
months, so I don't think that upstream's paying attention to it.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux cush 2.4.20 #1 Wed Apr 9 19:06:03 EDT 2003 i686
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages apache-common depends on:
ii libc6 2.3.1-16 GNU C Library: Shared libraries an
ii libdb2 2:2.7.7.0-8 The Berkeley database routines (ru
ii libexpat1 1.95.6-4 XML parsing C library - runtime li
ii perl [perl5] 5.6.1-8.2 Larry Wall's Practical Extraction
Reply to: