Recent changes to bugs

Vary header is sometimes truncated

Ethan Fischer — Sat, 10 Jan 2009 00:00:19 -0000

When mod_gzip_send_vary is "on" and a reqheader is defined, mod_gzip will send a Vary header to apprise web caches that there may be different versions of the file available.

The code which generates Vary headers for reqheader entries uses an uninitialized character array, which interacts badly with a broken implementation of mod_gzip_strncpy. The result is that the Vary header is sometimes truncated.

The problem is on line 1232 of mod_gzip-1.3.26.1a/mod_gzip.c, in mod_gzip_strncpy:

while(*s2 != 0 && *s1 != 0 && len <= l) {

This line checks both the source and target strings for null bytes. However, the target string is unintialized and allocated from the stack, having a high percentage of random zeroes in it. This causes the copy to stop partway through sometimes.

The easy way around this problem is to simply turn mod_gzip_send_vary off.

There are several ways to actually fix the problem. The way I prefer is to use the libc strncpy and check the length of the string we're copying to avoid overflow, like so:

char *mod_gzip_generate_vary_header(mod_gzip_conf *cfg,struct pool *p) {
int i = 0;
int len = 0;
char name[MOD_GZIP_IMAP_MAXNAMELEN + 2];
array_header *ary = ap_make_array(p,cfg->imap_total_isreqheader+1,sizeof(char *));

*((const char **)ap_push_array(ary)) = ap_pstrdup(p,"Accept-Encoding");

for(i=0;i<cfg->imap_total_entries;i++) {
if(cfg->imap[i].type == MOD_GZIP_IMAP_ISREQHEADER) {
len = strstr(cfg->imap[i].name,":") - cfg->imap[i].name - 1;
if (len > MOD_GZIP_IMAP_MAXNAMELEN) {
/* Buffer is too small. Prefer to cache too many copies than send a broken header. */
continue;
}
strncpy(name,cfg->imap[i].name,len);
name[len] = '\0';
*((const char **)ap_push_array(ary)) = ap_pstrdup(p,name);
}
}

return ap_array_pstrcat(p,ary,',');
}

incorrect NO_CONTENT_TYPE_IN_RESPONSE_HEADER

Anonymous — Mon, 07 Jun 2004 16:40:34 -0000

If the response header contains "content-type" instead
of "Content-type" mod_gzip returns an incorrect
NO_CONTENT_TYPE_IN_RESPONSE_HEADER.

JDK 1.3.1_06 puts the all lower case "content-type" in
the reponse header if you use response.setContentType
("text/html"). If I change this to response.setHeader
("Content-type","text/html") or even "ConTent-typE"
gzip handles it correctly. It only fails when the response
header has a lower case "c" in "content-type".

The exact error logged is:
mod_gzip:
SEND_AS_IS:NO_CONTENT_TYPE_IN_RESPONSE_HEADER
In:0 -< Out:0 = 0 pct.

I am running Apache 1.3.31 on Win2K, mod_gzip
1.3.26.1a.

HTTP Error 500

Anonymous — Tue, 30 Mar 2004 14:29:07 -0000

Mod_gzip works fine, but about 1 on 10 request is
finished with Apache 500 Error (Internal Server Error).

My configuration is: Apache 1.3.23 PHP4.3.5 mod_gzip
1.3.26.1a

Makefile or Documentation Bug

Michael Croft — Wed, 26 Nov 2003 04:39:22 -0000

Had to modify the makefile to compile under Apple OS X
10.3 (Panther).

1: APXS location is /usr/sbin/apxs

2: Changed Build target from
build:
$(APXS) -Wc,-Wall,-O3,-fomit-frame-pointer,-pipe -c
mod_gzip.c mod_gzip_debug.c mod_gzip_compress.c -o
mod_gzip.so
to
build:
$(APXS) -Wc,-Wall,-O3,-fomit-frame-pointer,-pipe -c
mod_gzip.c mod_gzip_debug.c mod_gzip_compress.c

then it makes, installs, and works.

Duplicate Content-Length Header

Thomas Nolting — Mon, 24 Nov 2003 15:47:56 -0000

Hello,
we use Apache as a web server frontend for the IBM
WebSphere Application Server. To improve performance
we would like to compress the dynamically generated
content with mod_gzip.
Although the response times with mod_gzip are in the
average much better than without compression, we
found out that some applications perfom really poor. It
seems as if the requests would "hang" for a long time
and suddenly the content was flushed to the client.
Without mod_gzip the same applications respond pretty
fast.
It turned out that under some circumstances,
WebSphere includes a "content-length" HTTP-Header in
the response. It is the number of bytes before
compression. It seems that mod_gzip does not recognize
this header (low cases!!) and does not replace it.
Instead it includes another HTTP-Header "Content-
Length" (the number of bytes after compression).

The browser (we tested with MS Internet Explorer)
seems to interpret the first header ("content-length") -
generally less bytes than the actual response has - and
waits for the rest of the bytes until it is timed out.

Correct me if I'm wrong, but as far as I know the HTTP
protocol does not specify that HTTP-Headers have to be
written in upper, lower or mixed case. Accordingly
the "content-length"-Header should be encountered and
replaced.
Since mod_gzip uses the Apache API (ap_table_set())
this could also be a bug in the Apache API.

Best regards,
Thomas Nolting

remote exploit (with debug mode)

Anonymous — Sun, 23 Nov 2003 09:26:10 -0000

http://www.securityfocus.com/archive/1/345094/2003-11-20/2003-11-26/0

apache/mod_rewrite/mod_gzip and Expect: 100 header

Dallas Beek — Mon, 17 Nov 2003 20:19:18 -0000

If the Expect: 100-continue header is passed in a
request to the apache server
which has mod_rewrite configured to forward the
request to an IIS server the
resulting page is never zipped by mod_gzip. Removing
the Expect: 100 header
returns a zipped page. The mod_gzip log looks like this.

Successful zip
10.254.33.174 - - [16/Oct/2003:18:10:24 -
0700] "qagateway01.qa.myco.com
POST /ws/api.dll HTTP/1.1" 200 477 mod_gzip: OK
In:1258 -< Out:262 = 80 pct.

Unsuccessful zip
10.254.33.174 - - [16/Oct/2003:18:54:32 -
0700] "qagateway01.qa.myco.com
POST /ws/api.dll HTTP/1.1" 200 1480 mod_gzip:
SEND_AS_IS:NO_200 In:0 -< Out:0 =
0 pct.

The headers in the unsuccessful response look like this.
It's difficult to
tell if both headers are part of the same response.

HTTP/1.1 100 Continue

HTTP/1.1 200 OK
Date: Fri, 17 Oct 2003 01:30:18 GMT
Server: Microsoft-IIS/4.0
Content-Type: text/xml
Content-length: 1258
X-Cache: MISS from qagateway01.qa.ebay.com
Connection: close

The request is also zipped if mod_rewrite is removed
from the equation
regardless of the Expect: 100-continue header.

Unfortunately Expect: 100-continue is required in
MS .Net httpwebrequest class
but I was also able to replicate this bug with a perl
script.

handlers called twice?

Chris Nandor — Fri, 14 Nov 2003 18:10:08 -0000

When mod_gzip is enabled, some of my other Apache
handlers are called twice (particularly, the PerlAccessHandler
handlers). Is there a way to prevent this?

In the handlers, I am already doing a return DECLINED unless
$r->is_main, so it is not subrequests, but actually two main
requests to my handlers.

Apache compilation module

Anonymous — Tue, 22 Jul 2003 09:49:25 -0000

Apache cant compile due to the mod_gzip.c (1.26.***)

Here is my compilation line :
./configure
--prefix=/usr/local/apache
--activate-module=src/modules/php4/libphp4.a
--enable-suexec
--suexec-caller=nobody
--suexec-userdir=www
--suexec-docroot=/home
--suexec-logfile=/usr/local/apache/logs/cgi.log
--suexec-uidmin=99
--suexec-gidmin=99
--suexec-safepath=/usr/local/bin:/usr/bin:/bin
--enable-module=so
--enable-module=rewrite
--add-module=src/modules/extra/mod_gzip.c
--enable-module=ssl
--enable-module=vhost_alias
--add-module=src/modules/extra/mod_bandwidth.c

make fails at the last compilation : httpd :

modules/extra/libextra.a(mod_gzip.o): In function
`mod_gzip_encode_and_transmit':
mod_gzip.o(.text+0x5968): undefined reference to `gzp_main'
modules/extra/libextra.a(mod_gzip.o): In function
`mod_gzip_compress_file':
mod_gzip.o(.text+0x62a7): undefined reference to `gzp_main'

please help me...

Thank you

Florent : superfc@superfc.dyndns.org

Apache 1.3.28 - Increased TRANSMIT_ERRORs

David T. — Sun, 20 Jul 2003 18:12:06 -0000

Might be specific to my system, but since upgrading to Apache
1.3.28 I'm getting increased TRANSMIT_ERRORS on my
slashcode based site (Redhat 7.1). Example:

[Sun Jul 20 17:46:57 2003] [error] mod_gzip:
TRANSMIT_ERROR:ISMEM:104
[Sun Jul 20 17:51:01 2003] [error] mod_gzip:
TRANSMIT_ERROR:32

Using Konquerer at home the browser will hang on a page
request on average once every 20 page loads and after
cancelling the request the transmit error will occur.

I have upgraded to mod_gzip/1.3.26.1a (DSO) but it still
occurs. I have not had any problems with Apache upgrades &
mod_gzip in the past.