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

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

実際にインストールを行うことは難しくありませんが、Apacheインストールのニーズに最も適した方法を見つけるには時間がかかる場合があります。

したがって、操作方法を選択し、インストールを実行する前に、この章を完全に読み、さまざまなオプションの長所と短所を理解することを強くお勧めします。

この文書は、特にmod_gzipのApacheモジュールとしての内部処理モデルをカバーしており、したがって、設定ディレクティブの評価方法を理解するために役立つ情報を提供する可能性があります。

基本

はじめに

Apacheウェブサーバーは、モジュールをプログラムコードに統合するための2つの異なる方法をサポートしています:

静的統合と
動的統合。

使用するApacheサーバーの運用コンセプトと与えられた要件に応じて

mod_gzipのこれら2つの操作方法のいずれかを選択する必要があり、
この方法に必要なファイルのセットをダウンロードする必要があります。

Apacheモジュールの静的統合

静的統合とは、モジュールがApacheサーバーを実装するリンクされたプログラムバイナリ httpd の永続的な部分になることを意味します。

これには、Apacheサーバーのソースコードを

このモジュールのソースコードで拡張し、次に
Cコンパイラを使用して全体をコンパイルする必要があります。

通常、各管理者は自分の要件に合わせてApacheサーバーの異なる機能セットを使用したいと考えるため、多数のプラットフォームで実行可能なプログラムファイルを提供することは現実的ではないようです。

Apacheモジュールの動的統合

動的統合とは、モジュールがApacheプロセスを開始する際に、共有オブジェクトとして別のモジュールファイルから読み込まれることを意味します。

これには

必要なターゲットプラットフォーム用のこのモジュールの共有オブジェクトファイルを取得または生成し、
対応するApacheディレクトリにインストールし、
このモジュールを読み込むためのディレクティブでApache設定ファイルを拡張する必要があります。

mod_gzipのモジュールソースコードの構造

ほとんどのApacheモジュールは、1つのソースコードファイルのみで構成されています。このファイルは、apxsプログラムを呼び出すことでコンパイルできます（対応するパラメータ値を使用）。この方法で作成された共有オブジェクトのインストールには、もう1回apxsを呼び出す必要があります（異なるパラメータ値で）。

バージョン1.3.26.1a以降、mod_gzipのソースコードは3つの別々のファイルに分かれています:

mod_gzip.c（約8000行）は、mod_gzip Apacheモジュールの処理ロジックを実装するために必要なすべての関数を含んでいます。
このファイルは、Apacheバージョン1.3のモジュールインターフェースに非常に依存しています（これは何年も変更されていません）。
mod_gzip_debug.c（約500行）は、開発者のためのデバッグタスクに必要な関数を含んでいます; これらの関数の一部は、mod_gzipが「通常の方法」でコンパイルされた場合には含まれていません（ -D タイプの与えられたコンパイラディレクティブの値に依存します）。
mod_gzip_compress.c（約3000行）は、Kevin Kileyによるgzip圧縮関数の実装を含んでいます。これは「実際に作業を行う」ものです。
この部分は特定のApacheバージョンに依存せず、（純粋に技術的な観点から）他の圧縮ツールでも使用される可能性があります（mod_deflateのように、現在は圧縮に「zlib」を使用しています）。

このソースコードの構造により、mod_gzipのメンテナンスが少し容易になり、インストールが少し複雑になります（これにより、1つのファイルではなく複数のソースファイルをコンパイルする必要があります）。したがって、mod_gzipはこのインストールプロセスを簡素化するためにMakefileを提供しています。

ダウンロード

上記の運用コンセプトのいずれかを実行するために、異なるファイル（それぞれの使用目的に適した）を使用する必要があります。

執筆時点で、mod_gzipプロジェクトのダウンロードページには、各mod_gzipバージョンに対して以下のファイルが利用可能です:

| mod_gzip- version .tgz: | mod_gzip製品のgzip圧縮tarアーカイブで、以下を含みます - モジュールのソースコード（Cプログラミング言語で）、

複数のMakefile（ソースコードをコンパイルするため）、
Change-Log（すべてのプログラムバージョンの最も重要な変更の短いドキュメント）および
手元のドキュメント。 | | ApacheModuleGzip.dll.zip: | Windowsプラットフォーム用のmod_gzipの共有オブジェクトファイルを含むZIPアーカイブ。 | | mod_gzip- version -FreeBSD-4.6-i386.so.gz: | FreeBSD-UNIX 4.6プラットフォーム用のmod_gzipの共有オブジェクトファイルを含むgzip圧縮ファイル。 | | mod_gzip.so.gz: | Solaris 2.7プラットフォーム用のmod_gzipの共有オブジェクトファイルを含むgzip圧縮ファイル。 |

もしmod_gzipが他のプラットフォームで動的統合で実行される場合は、そのプラットフォーム用の共有モジュールファイルを管理者が作成する必要があります。

mod_gzipの静的統合

Apacheウェブサーバーの通常のコンパイル

Apacheグループによって文書化されたUNIXマシン上でのApacheウェブサーバーのインストール手順は、次のようになります（短縮版）:

WWWからApacheソースコードのアーカイブをダウンロード
アーカイブを解凍
前の操作で作成されたディレクトリに移動
INSTALLファイルを読み、理解する
./configureシェルスクリプトを適切なパラメータ値で開始する（これにより、多くのサブディレクトリにMakefileファイルが作成されます）
make install（これにより、Apacheサーバーとそのオンラインドキュメントのコンパイルとインストールが行われます）

このようにしてApacheウェブサーバーが作成された場合、出荷されたモジュールは通常、Apacheプログラムディレクトリ内の作成されたプログラムファイルhttpdの静的部分になります - ただし、configure呼び出しのパラメータで異なるものを指定しない限り。

（configureの実際の呼び出しは、標準パラメータ値からの逸脱の程度に応じて非常に広範になる可能性があります。この呼び出し自体を小さなシェルスクリプトに保存して、処理されたインストールの種類を文書化することをお勧めします。）

mod_gzipのApacheソースコードへの統合

公式のApacheモジュールのソースコードは、解凍されたApacheソフトウェアのtarアーカイブのsrc/modulesサブディレクトリに含まれています。

mod_gzipをこのメカニズムで標準のApacheモジュールとして扱うためには、次の準備が必要です:

mod_gzipソースコードを含むダウンロードアーカイブの内容を解凍し、展開する（これによりmod_gzip- versionnumberというディレクトリが作成されます）、
Apacheソースのディレクトリツリー内にsrc/modules/gzipというディレクトリを作成する
拡張子が.c*、.h、.tmplのすべてのファイルをこの新しいgzipディレクトリにコピーします。

次のステップとして、configure呼び出しを–activate-module=src/modules/gzip/mod_gzip.cというパラメータで拡張します。これにより、configureスクリプトはmod_gzipソースコードを見つけ、出荷されたMakefile.tmplファイルから適切なMakefileを作成します - メッセージによって記録されます

 + activated gzip module (modules/gzip/mod_gzip.c)

と

Creating Makefile in src/modules/gzip**

後者はApache自身のモジュールと同じように。 (mod_gzipに付属のMakefileはこのタイプのインストールには適していません - これは共有オブジェクト*ファイルの作成のためのものです。)

これでApacheのインストールは通常通りに機能し、mod_gzipは通常のApacheモジュールのように扱われます。

しかし、configureは、–activate-moduleパラメータを介して統合されたモジュールが特定の要件を持つ可能性がある3rdパーティモジュールであることを認識しており、したがって、mod_gzipをモジュールスタックの上に自動的にロードして、他のすべてのモジュールの前に到着するHTTPリクエストにアクセスできるようにします - これはmod_gzipが緊急に必要とするものです。

一部のプラットフォームでは、Apacheのconfigureが$(LIBEXT)環境変数の値を適切な.aの値に自動的に設定しないようです。この場合、mod_gzipのコンパイルは失敗します。この動作の正確な理由は現在不明ですが、ワークアラウンドとして、次の行を置き換えることができます

LIB=libgzip.$(LIBEXT)

を

LIB=libgzip.a

に、すなわち適切な値を手動で挿入します。

この作業には、タブ文字を空白に展開しないエディタを使用してください！

（テストすべきこと: –activate-moduleで複数の 3rdパーティモジュールを統合するとどうなるか？この場合、パラメータ値の順序は重要ですか？）

mod_gzipが正しく統合されたか確認する

mod_gzipが実際に要求された通りにApacheプログラムコードに統合されたかどうかを確認するには、Apacheサーバーが提供するhttpd -lコマンドを使用します。これにより、統合されたすべてのモジュールのリストが表示されます（読み込まれる順序で）; mod_gzip.cは表示される最後のエントリであるべきです。

mod_gzipの動的統合

読み込み可能なApacheモジュールの概念

Apacheウェブサーバーは、読み込み可能なモジュールの概念をサポートしています。

ほとんどのApacheモジュールは

共有オブジェクトとしてコンパイルされ、次に
Apacheサーバーの起動時にApacheのアドレス空間に動的にロードされます（対応する設定ディレクティブを使用して）。

読み込み可能なモジュールの取り扱いには、Apache設定に関する追加の知識が必要です（これらのモジュールが読み込まれる順序がその機能にとって重要である可能性があるため）が、Apacheサーバーのコード範囲を再コンパイルすることなく変更することを可能にします。

Windowsのようなプラットフォームでは（多くのApache管理者がApacheコードをコンパイルしてリンクするためのC開発環境を持っていないため）、読み込み可能なモジュールの使用はしばしばApacheサーバーの機能範囲を拡大するための唯一の可能性となります。

Apache 1.3のドキュメントは、このトピックに関する以下の記事を提供しています:

動的共有オブジェクト（DSO）サポート - Apacheウェブサーバーの対応する概念の説明
モジュールmod_so - 他のモジュールを読み込むためのApacheモジュールの説明と必要な設定ディレクティブ

mod_gzipを読み込むためのディレクティブ

mod_gzipの共有オブジェクトをApacheコードに動的に追加するには、次のいずれかの設定ディレクティブが必要です:

# ---------------------------------------------------------------------  
# DLLを読み込む / Windows:  
  LoadModule gzip_module modules/ApacheModuleGzip.dll  
# ---------------------------------------------------------------------  
# DSOを読み込む / UNIX:  
  LoadModule gzip_module modules/mod_gzip.so  
# ---------------------------------------------------------------------  
# （モジュールが静的に統合されている場合はどちらも使用しない）  
# ---------------------------------------------------------------------

実際のファイル名は自由に選択できます - 実際に使用されるファイルの名前と一致する必要があります。一方、この名前はオペレーティングシステムプラットフォームや、このモジュールのコンパイル方法によって異なる場合があります - この場合、上記のディレクティブを適応させるか、ファイルの名前をそれに応じて変更する必要があります。

Apache 1.3によるモジュールの取り扱い

Apacheサーバーは任意の数のモジュールを動的にロードできます。この際、対応するLoadModuleディレクティブは、設定ファイル内での発生順に処理されます。

しかし、モジュールは作業メモリ内のスタックにロードされます: 最後にロードされたモジュールが、Apacheウェブサーバーへの対応するHTTPリクエストを処理するための最初のアクセスを得ることになります - そして、そのリクエストを処理する責任があるかどうかを決定することができます。

Apache 1.3では、問題のすべてのモジュールのうち1つだけがリクエストの処理に責任を持つことができます - 後続のモジュールは尋ねられることすらありません。

mod_gzipのリクエスト評価への統合

したがって、任意のモジュールの出力を処理できるようにするために、mod_gzipは実際にはApache 1.3アーキテクチャに矛盾することをしなければなりません: リクエストを「処理」しなければならず、その後このリクエストの処理に対する責任を取り消さなければなりません。この手順によって、実際にリクエストを処理する責任があるモジュールがApacheサーバーによってすべてアクティブ化されることができます。

この最初の段階で、mod_gzipによるこのリクエストの「処理」は、提供されるページの内容を圧縮することを意味しません - なぜなら、この内容はまだ存在せず、他のモジュールによって生成される必要があるからです！代わりに、この時点でmod_gzipは、ページ内容の生成後に何かを行いたいかどうかを再度尋ねられる準備をするだけです。このアクティベーションの第2段階（HTTPレスポンスの内容がすでに利用可能な状態）で、mod_gzipはHTTPレスポンスパケットの内容を圧縮するという本質的な作業を実行できます（および特定のHTTPヘッダーの修正）。

mod_gzipによるこのHTTPレスポンスの後処理のための「登録」は、mod_gzipがこの段階で、処理内容に興味がないことをすでに判断できない場合にのみ必要です。

したがって、この最初の段階でmod_gzipは、Apache設定で指定されたフィルターディレクティブの評価の一部をすでに実行します: リクエストの説明に基づいてこれを行うことができるルールをチェックします（すなわち、対応するHTTPヘッダーの内容）。これは、mod_gzip_item_include / mod_gzip_item_excludeルールのタイプに適用されます

reqheader（リクエストのHTTPリクエストヘッダーの内容）、
url（要求されたHTTPリソースのURL）、
file（このリクエストに影響を与えるファイル名、すべてのAlias翻訳などを評価した後）および
handler（Apache設定に従ってこのリクエストの評価を担当するハンドラーの名前）。

これらのフィルタールールの評価がすでに、このリクエストの結果が圧縮されるべきではないことを示している場合、すなわち

少なくとも1つのexcludeルールが満たされているまたは
どのincludeルールも満たされていないまたは
圧縮を実行するための他の条件が満たされていない場合（たとえば、この段階でクライアントがAccept-Encoding: gzip HTTPヘッダーを送信して圧縮データの提供を許可しているかどうかをすでに確認できます）

この場合、mod_gzipはレスポンス内容の生成後に残りのルールをチェックする必要がないため、そうはなりません。mod_gzipは、各リクエストの最初の評価段階の結果を記憶し、この場合は第2段階を即座に終了します。

そうでなければ、動作の第2段階でmod_gzipは、生成されたレスポンスパケットの実際の内容に基づいてのみ評価できる残りのフィルタールールをチェックします:

rspheader（HTTPレスポンスヘッダーの内容）および
mime（結果のHTTPコンテンツタイプ）。

さらに、レスポンスパケットのサイズ（ディレクティブmod_gzip_minimum_file_sizeおよびmod_gzip_maximum_file_size）など、他のいくつかの条件が現在テストされます。

そして、すべてのテストが肯定的な結果をもたらした場合にのみ、レスポンスパケットの圧縮が実際に実行されます。

mod_gzipのすべてのApacheモジュールの読み込み順序内での位置

上記のすべてのタスクを実行できるようにするために、mod_gzipモジュールは、処理されるHTTPリクエストを他のすべてのApacheモジュールの前に処理するアクセスを持っている必要があります。すべてのApacheモジュールのリクエスト処理へのアクセスの順序が逆であるため、mod_gzipはすべてのApacheモジュールの最後に読み込まれるべきです。

静的統合の場合、このモジュールの順序は、Apacheソースコードのコンパイル中にhttpdプログラムの「設計図」によって定義されます。Apacheグループが出荷したApacheソースコードのコンパイル手順は、出荷されたモジュール間のすべての依存関係を知っており（これらのモジュールの対応する順序を確保します）、configureパラメータ–add-module= fileによってコンパイルプロセスに統合される3rdパーティモジュールの要件は知りません。これらの3rdパーティモジュールに最大限の影響を与えるために、そのようなモジュールはモジュールスタックの最後のモジュールとして読み込まれます。

したがって、mod_gzipが唯一の 3rdパーティモジュールとしてApacheサーバーに統合される場合、configureは自動的に正しいことを行います。複数の3rdパーティモジュールを使用する場合、管理者がこれらのモジュールの順序を責任を持って決定する必要があります（おそらく–add-module=の値の順序によって？まだテストしていません）。

apxsを使用したmod_gzipのコンパイル

Apacheコンパイルユーティリティapxsの機能

Apacheサーバーがモジュールの動的統合をサポートするように運営されている場合（すなわち、mod_soモジュールを使用している場合）、Apacheのインストール中にApacheのbinディレクトリにapxsという名前のユーティリティプログラムが生成されます。

このプログラムは、Apacheモジュールのプログラムソースコードをコンパイルし（Cコンパイラを使用）、対応する共有オブジェクトファイルを作成することを可能にします。これにより、Apacheサーバーの完全なソースコードが利用可能である必要はありません: apxsは必要なすべてのApacheプログラムインターフェースを知っており、Cコンパイラに必要な情報を提供します。

makeを使用してmod_gzipの共有オブジェクトを作成する

ユーザーがapxsを使用してmod_gzipを完全にコンパイルおよびインストールする方法を見つける手間を省くために、ソースコードアーカイブ内にMakefileという名前のファイルが提供されています。

このMakefileを使用することで、インストール手順は次のステップに短縮されます:

ダウンロードしたmod_gzipソースコードアーカイブファイルからファイルを抽出し、選択した（新しい、一時的な）ディレクトリに移動し、現在のディレクトリ位置をそこに変更します。
Apacheインストールからapxsプログラムのパス名を調べます。
コマンドを実行してコンパイルを行います
```
make         APXS=*your_apxs_pathname*
```
（この操作のステップは省略可能です。次のステップでカバーされます。）

コマンドを実行してインストールを行います

make install APXS=*your_apxs_pathname*
``` これにより、*共有オブジェクト*ファイルがApacheインストールの対応するディレクトリにコピーされるだけでなく、必要な*LoadModule*および*AddModule*ディレクティブによってApache設定ファイル*httpd.conf*が自動的に拡張されます... 外部プログラムに貴重な設定ファイルを書き換えられたくない場合は、この最終ステップを手動で実行するか、少なくともApache設定のバックアップを作成することをお勧めします。

これらの必要なステップに加えて、Makefileは以下のコマンドをサポートしています（これらはむしろ開発者にとって関心があるかもしれません）:

make cleanは、現在のディレクトリからmod_gzipソースコードファイルのすべての作成されたオブジェクトモジュールファイルを削除します（すなわち、すべてのファイル名パターン*.o）。
make cleanはさらに作成された共有オブジェクトファイルmod_gzip.soも削除します。

この文書の元の場所:

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

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

基本