Antwort: Re: Antwort: Re: [Mod_gzip] SEND_AS_IS:HAS_CE message

[mod_gzip@lists.over.net]

Hi all,


> GET /liwen/php/mail.php HTTP/1.1" 200 432 mod_gzip: DECLINED:EXCLUDED
In:0 -< Out:0 = 0 pct.
> GET /liwen/index.htm HTTP/1.1" 200 808 mod_gzip: OK In:572 -< Out:380 =
34 pct.
> I think all work. Regarding php file compression, I have added php
extension
> as an excluded item in mod_gzip config file. So, mail.php is treated as
> "DECLINED:EXCLUDED". Is it right ?

you don't actually need this exclusion rule to make mod_gzip 'work'.

All you cause to happen is that you make mod_gzip detect _earlier_
that it has no business with this response:
a) If you exclude the PHP scripts from mod_gzip handling explicitly,
   then mod_gzip will find this out in rule evaluation phase 1;
b) if you don't, then mod_gzip will detect the Content-Encoding
   being applied by the PHP compression module in phase 2.
The result is always the same: mod_gzip won't change the content.
The only difference is the mod_gzip status code in your access_log.

You may even put the decision into some earlier phase of the request
evaluation, by using <Files> to exclude even the invocation of
mod_gzip at all for some requests.
And given the recent problems with the M$IE handling "Vary:" headers
for images, it may even be necessary doing so in certain cases.

> BTW, I have also input "mod_gzip_item_include file  ^^.*\.php.*$" to
mod_gzip.conf file

You can omit "^^.*", because it has no effective meaning.
You can omit ".*$" as well, because of the same reason.

All you need to write is

     mod_gzip_item_include file  \.php

with the meaning "include if you find the substring '.php' within
the file name". This is how regular expressions should be used, IMHO.



Finally, about the different file sizes being produced by mod_gzip
and the PHP compression module:
Not long ago we had a thread here about the compression effect of
mod_gzip vs. mod_deflate (Apache 2.x). The result was that
- mod_gzip is the equivalent of "gzip -6", while
- mod_deflate (of Apache 2.0) was the equivalent of "gzip -1"
  (later Apache 2 versions will provide a parameter for the compres-
  sion quality).
As your output compressed by PHP was always a little smaller than
the mod_gzip output, I suspect PHP to use the equivalent of "gzip -9".

Thus it is your choice now:
- You may either let PHP compress the content (and produce maximum
  quality for a maximum of CPU load),
- or let mod_gzip compress the content, and get some 9x% of the
  quality for a reasonably lower CPU load.
Ultimately, it all depends on what you want to get and which price
you are able & willing to pay for it.

Regards, Michael