[Mod_gzip] Antwort: a patch for fixing lower case headers(content-encoding, transfer- encoding)

[mod_gzip@lists.over.net]

Hi Jin,


> Recently I found that the current mod_gzip(version 1.3.26.1a)
> can not recognize HTTP headers starting with lower case characters,
> esp, content-encoding and transfer-encoding.
> This can cause HTTP responses which are already compressed to be
> compressed by mod_gzip again.
> I found this problem when testing a commercial java application
> framework(WebObjects, see http://developer.apple.com/webobjects/)
> which outputs all HTTP headers in lower case characters.

... which looks definitely legal in terms of RFC 2616, as I
tried to doublecheck right now - just to note that here.

> Even I gzip compress HTTP responses in java and set "Content-Encoding:
> gzip", mod_gzip still try to compress them. After changing mod_gzip
> source code(mod_gzip.c) to have it recognize headers starting with
> lower case characters also, it can recognize header "content-encoding:
> gzip" and send the compressed response as it.
> The attached file is the patch for this small fix. Since I know nothing
> about Apache module programming, this patch is just a hack to make
> thing work first. There must be better solutions to this problem.

I insert your patch here, as a copy of this will go to the mod_gzip
mailing list:

--- mod_gzip.c	Sat Apr 26 15:15:49 2003
+++ mod_gzip.c.orig	Wed Mar 26 14:46:03 2003
@@ -5530,7 +5530,7 @@
                   #endif
                  }

-               else if ( lbuf[0] == 'T' || lbuf[0] == 't' )
+               else if ( lbuf[0] == 'T' )
                  {
                   if ( mod_gzip_strnicmp(lbuf,"Transfer-Encoding:",18)==0)
                     {
@@ -5553,7 +5553,7 @@
                     }
                  }

-               else if ( lbuf[0] == 'C' || lbuf[0] == 'c' )
+               else if ( lbuf[0] == 'C' )
                  {
                   if ( mod_gzip_strnicmp(lbuf,"Content-Encoding:",17)==0)
                     {
@@ -6912,7 +6912,7 @@
               {
                ok_to_send = 1;

-               if ( lbuf[0] == 'T' || lbuf[0] == 't' )
+               if ( lbuf[0] == 'T' )
                  {
                   if ( mod_gzip_strnicmp(lbuf,"Transfer-Encoding:",18)==0)
                     {
@@ -6944,7 +6944,7 @@
                  }
                #endif

-               else if ( lbuf[0] == 'C' || lbuf[0] == 'c' )
+               else if ( lbuf[0] == 'C' )
                  {
                   if ( mod_gzip_strnicmp(lbuf,"Content-Encoding:",17)==0)
                     {



> The following log was produced before applying the patch.
> ##############################################################
> mod_gzip: DECLINED:ORIGINAL_SMALLER In:8506 -< Out:8507 = 0 pct.
> ##############################################################
>
> The following log was produced after applying the patch.
> ##############################################################
> mod_gzip: SEND_AS_IS:HAS_CE In:0 -< Out:0 = 0 pct.
> ##############################################################

Looks as if the behaviour is much better now. ;-)

> Please let me know if you guys think a solution to fix this problem
> is necessary and the fix can be accepted for future mod_gzip releases,
> otherwise I have to maintain my own version of mod_gzip due to this
> problem.

I agree with you that this is a bug in mod_gzip which doesn't
support all variants of legal HTTP headers while searching
for an already applied encoding.

Thus I would suggest adding this patch (or maybe some variant
of it - I am not the C programmer; maybe the mod_gzip_strnicmp
function itself should rather be used there?) to the next
version, whenever this one will be released.
Right now, all I can do is accept it and document it. But I
hope you will not have to maintain any separate source tree.

Thank you for finding, fixing and posting this bug!

Regards, Michael