Antwort: [Mod_gzip] Apache 1.3.23 + mod_gzip 1.3.19.1a + ColdFusionMX

[mod_gzip@lists.over.net]

Hi Ian,


> mod_gzip_item_include handler jrun-handler
> mod_gzip_item_include handler handler-jrun
> mod_gzip_item_include handler type-coldfusion

this type of "guessing game" - how might the handler name
of the product you are using actually be? - is the reason
why it is a top priority for me to let the next mod_gzip
release set Apache notes for the actual values being used
while doing the rules checking so that one can have them
logged inside the access_log, and be aware what should
have been inside his/her rule set.

> And from my log:
> xx.xx.xx.xx - - [03/Oct/2002:15:05:13 -0400] "server.com GET /test.html
HTTP/1.1"
> 200 1783 mod_gzip: OK In:9003 Out:1783:81pct.

This works.

> xx.xx.xx.xx - - [03/Oct/2002:15:07:27 -0400] "server.com GET /style.css
HTTP/1.1"
> 304 - mod_gzip: DECLINED:EXCLUDED In:0 Out:0:0pct.

This is explicitly excluded.

> xx.xx.xx.xx - - [03/Oct/2002:15:07:26 -0400] "server.com GET / HTTP/1.1"
> 200 8273 mod_gzip: DECHUNK:OK In:35461 Out:8273:77pct.

This works (due to the dechunking being activated).

> xx.xx.xx.xx - - [03/Oct/2002:15:09:40 -0400] "server.com GET /index.cfm
HTTP/1.1"
> 200 35559 mod_gzip: - In:- Out:-:-pct.

Oops. mod_gzip isn't even invoked here.
In which order are you loading your modules?

> So, you can see that mod_gzip is working, it compresses test.html, and
> /index.cfm when references as /. But it won't compress /index.cfm, or
> any other .cfm for that matter when I access them directly.

Which MIME type is your request producing?
I am missing this field in your log file format.



Regards, Michael