Possible enhancements in future versions of mod_gzip
Author: Michael Schröpl
Description: A list of (hopefully) reasonable and probably easy to implement functional enhancements for further mod_gzip versions
Keywords: Apache, HTTP, encoding, gzip, compression

# Possible enhancements in future versions of `mod_gzip`

This document describes some possible functional enhancements which hopefully could be implemented into the current version 1.3.26.1a of `mod_gzip` without too much effort and enhance the usability of this module.

## Logging class and value of the decisive filter rule

The decision about whether a document content qualifies for compression by `mod_gzip` is finally done during the evaluation of the filter rules defined by the directives `mod_gzip_item_include` and `mod_gzip_item_exclude` which are checked by the function `mod_gzip_validate1`.

But this function is invoked at no less than five positions within the source code, each time with different parameter settings for specific parts of the rules classes to be checked at that moment. In some of these cases it is clear from the restricted parameter setting which rule class must have led to the specific result (but not which rule value!), in other cases (such as the simultaneous test of all rules of the classes `file`, `uri`, `mime` and `handler`) not even the class of the decisive rule is clear (because `mod_gzip_validate1` returns such an unspecific result value to the caller that this one cannot even understand what exactly has happened - in some cases even internal errors are encoded like a decision because of an exclusion rule). In these cases not even a reasonable evaluation of the `mod_gzip` status code is possible.

But the definition of an appropriate rule set is the most important step during the complete (and currently still rather complicated) `mod_gzip` configuration procedure. Any information about which one of the defined rules decided in which cases about whether a document content was to be compressed would be helpful for the user in many cases.

On the other hand `mod_gzip` already supports processing transparency after successfully handling a document by setting some variables which can be used in Apache log formats (the processing status, the document sizes before and after compression as well as the volume saving in percent - the last one erroneously always rounded up). According to this `mod_gzip` could (just in the moment when the decision about compressing the document content was made) easily store class and content of the decisive rule into two more log variables which would then be addressed withing a log format via the names `mod_gzip_rule_class` and `mod_gzip_rule_content`.

## Configurable gzip compression level

Currently `mod_gzip` uses the `gzip` compression level 6. This is hard-coded by the assignment `gz1->level = 6` inside the function `gz1_init`.

The higher the compression level, (`gzip` normally allows values between 0 and 9), the better the compression effect, but the higher the CPU time consumption as well. By adapting this compression level a user could solve the trade-off between CPU load and bandwidth saving according to his own requirements. Own experiments have shown that level 3 already takes you near the effect of compression level 6 - at least the choice between these two values should be left to the user.

Thus it would be reasonable to have this compression level configurable by offering another directive `mod_gzip_compression_level`.

## Boolean expressions in `include`/`exclude` directives

`mod_gzip` 1.3.19.1a uses - caused by its way of being embedded inside the Apache request handling - a complex, two-level filter procedure to decide whether the result of a request should be compressed. (In a modified architecture of Apache 2.0 a simpler way of embedding might be possible.)

A request currently will be accepted by `mod_gzip` exactly if during each of the two decision phases at least one `include` rule fires but no `exclude` rule. As such rules allow for regular expressions as parameter values this makes powerful conditions available.

Nevertheless all rules are independent from each other; the directives currently available don't allow the user to express that distinct MIME types only be delivered in compressed form to distinct browsers - the `AND` connection between several rules is missing.

There seem to be only rare occasions where this would be really helpful - as of now, it would be especially required to fine-tune filter rules as to cope with all the bugs of Netscape 4, other than by totally excluding this browser from compression. With time passing (and improved standards compliancy of the browsers) this feature may become obsolete.

(Michael Schröpl, 2002-09-28)