mod_gzip - Apacheウェブサーバーによる圧縮コンテンツの提供 - ページ8

著者: マイケル・シュレプル

この文書では、mod_gzipの現在のバージョン1.3.26.1aにあまり手間をかけずに実装できる可能性のある機能強化について説明します。

ロギングクラスと決定的フィルタールールの値

mod_gzipによってドキュメントコンテンツが圧縮に適しているかどうかの決定は、最終的にはmod_gzip_item_includeとmod_gzip_item_excludeによって定義されたフィルタールールの評価中に行われます。これらはmod_gzip_validate1関数によってチェックされます。

しかし、この関数はソースコード内の5つの異なる位置で呼び出され、それぞれ異なるパラメータ設定で特定のルールクラスの部分をチェックします。これらのケースのいくつかでは、制限されたパラメータ設定からどのルールクラスが特定の結果を導いたかは明らかですが（ただし、どのルール値かは不明）、他のケース（file、uri、mime、handlerのすべてのルールの同時テストなど）では、決定的なルールのクラスさえも明確ではありません（mod_gzip_validate1が呼び出し元に対して非常に不特定な結果値を返すため、何が正確に起こったのかを理解できない場合があります - 一部のケースでは、内部エラーが除外ルールによる決定としてエンコードされることさえあります）。これらのケースでは、mod_gzipステータスコードの合理的な評価さえも不可能です。

しかし、適切なルールセットの定義は、完全な（現在はまだかなり複雑な）mod_gzip構成手順の中で最も重要なステップです。定義されたルールのうち、どれがどのケースでドキュメントコンテンツを圧縮するかを決定したかに関する情報は、多くのケースでユーザーにとって役立つでしょう。

一方、mod_gzipはすでに、圧縮されたドキュメントを正常に処理した後に、Apacheログフォーマットで使用できるいくつかの変数を設定することによって処理の透明性をサポートしています（処理ステータス、圧縮前後のドキュメントサイズ、およびパーセントでのボリューム節約 - 最後のものは誤って常に切り上げられます）。これに従って、mod_gzipは（ドキュメントコンテンツを圧縮する決定が下された瞬間に）決定的なルールのクラスと内容を2つの追加のログ変数に簡単に保存し、それらはmod_gzip_rule_classおよびmod_gzip_rule_contentという名前でログフォーマット内で参照されることができます。

設定可能なgzip圧縮レベル

現在、mod_gzipはgzip圧縮レベル6を使用しています。これはgz1->level = 6という割り当てによってgz1_init関数内でハードコーディングされています。

圧縮レベルが高いほど（gzipは1から9の値を許可します）、圧縮効果は良くなりますが、CPU時間消費も増加します。この圧縮レベルを調整することで、ユーザーは自分の要件に応じてCPU負荷と帯域幅の節約のトレードオフを解決できます。独自の実験により、レベル3でもすでに圧縮レベル6に近い効果が得られることが示されています - 少なくともこれら2つの値の選択はユーザーに委ねるべきです。

したがって、この圧縮レベルを設定可能にするために、別のディレクティブmod_gzip_compression_levelを提供することは合理的です。

クリスチャン・クルーゼによる詳細な調査により、ケビン・カイリーのmod_gzip用の圧縮コードは、基本的にレベル6に必要なものだけをサポートしており、すべての9つの圧縮レベルをサポートしていないようです（プログラム構造は後で9つのレベルを実装するために設計されていました）。したがって、前述の定数を単に変更するだけでは不十分であり、実際にはこの種の変更の後、mod_gzipはもはや使用できなくなります。

include / excludeディレクティブのブール式

mod_gzip 1.3.19.1aは、Apacheリクエスト処理内に埋め込まれているため、リクエストの結果を圧縮するかどうかを決定するために複雑な2レベルのフィルタ手順を使用します。（Apache 2.0の修正されたアーキテクチャでは、よりシンプルな埋め込み方法が可能かもしれません。）

現在、リクエストは、各の2つの決定フェーズで少なくとも1つのincludeルールが発火し、かつexcludeルールが発火しない場合にのみmod_gzipによって受け入れられます。このようなルールは正規表現をパラメータ値として許可するため、強力な条件が利用可能になります。

それにもかかわらず、すべてのルールは互いに独立しています。現在利用可能なディレクティブでは、特定のMIMEタイプが特定のブラウザに対してのみ圧縮形式で配信されることをユーザーが表現することはできません - 複数のルール間のAND接続が欠けています。

これが本当に役立つのは稀な場合のようです - 現在のところ、特にNetscape 4のすべてのバグに対処するためにフィルタールールを微調整する必要がありますが、このブラウザを圧縮から完全に除外する以外の方法はありません。時間が経つにつれて（ブラウザの標準準拠が改善されるにつれて）、この機能は不要になるかもしれません。

GETおよびHEADリクエストに対する同一のHTTPヘッダーの提供

RFC 2616によれば、HEADメソッドを使用するリクエストに対して、HTTP/1.1準拠の実装は、GETメソッドを使用して同じリソースに対するリクエストに対して提供されるはずのHTTPヘッダーと同一のものを提供する必要があります。

mod_gzipの場合、これはHEADリクエストに対してもコンテンツが圧縮される（または静的に事前圧縮されたファイルの場合は読み込まれる）必要があることを意味します。正しいContent-Length HTTPヘッダーを生成するためです。

現在、mod_gzipはこの（非常に稀な）アプリケーションのケースを処理していません（おそらくパフォーマンスの考慮から）。しかし、RFC 2119によれば、これはモジュールの動作がHTTP/1.1に対して条件付きでしか互換性がない原因となる可能性があります。なぜなら、推奨要件をサポートしない正当な理由が必要だからです。

この文書の元の場所:

http://www.schroepl.net/projekte/mod_gzip/enhancements.htm