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
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
Since mod_gzip uses the Apache API (ap_table_set())
this could also be a bug in the Apache API.
Log in to post a comment.