Linux システムでの Apache サーバーのセットアップと最適化

Apache サーバーの設定ファイルは、/usr/local/apache/conf/ ディレクトリにあります。従来、Apache の動作を構成するには、httpd.conf、access.conf、srm.conf の 3 つの構成ファイルが使用されます。サーバ。 httpd.conf は、最も基本的なサーバー構成を提供し、デーモン httpd がどのように実行されるかを技術的に説明します。srm.conf はサーバーのリソース マッピング ファイルであり、さまざまなファイルの MIME タイプとこれらのファイルのサポート方法をサーバーに伝えます。これは、サーバーのアクセス権を構成し、さまざまなユーザーやコンピューターのアクセス制限を制御するために使用されます。これら 3 つの構成ファイルは、サーバーの特性のあらゆる側面を制御するため、サーバーを正常に実行するには、これら 3 つのファイルを設定する必要があります。上。

これらの 3 つの設定ファイルに加えて、Apache は mime.types ファイルも使用して、さまざまなファイルに対応する MIME タイプを識別します。マジック ファイルは、Apache サーバーがさまざまな MIME タイプのファイルに特別な識別子を設定します。ドキュメントのサフィックスからの変更 ファイルの MIME タイプを特定できない場合、ファイル コンテンツ内のこれらの特殊マークによってドキュメントの MIME タイプを特定できます。

[iaspec@www conf]$ pwd

/usr/local/apache/conf

[iaspec@www conf]$ ls

アクセス。 conf httpd.conf.OLD magic.default srm.conf

access.conf.default httpd.conf.SAVE mime.types srm.conf.default

httpd.conf magic mime.types。デフォルト

Apache の新しいバージョンでは、元の httpd.conf、srm.conf、および access.conf のすべての設定パラメータが 1 つの設定ファイル httpd.conf にまとめられます。これは、以前のバージョンとの一貫性を保つためです。互換性の理由 (これら 3 つの設定ファイルを使用する方法は NCSA-httpd からのものです) のため、使用される構成ファイルは 3 つだけです。提供される access.conf および srm.conf ファイルには特定の設定はありません。

新しいバージョンの Apache では、すべての設定が httpd.conf に配置されるため、このファイルの設定を調整するだけで済みます。この記事では、例として redhat 7.2 の httpd.conf を使用して、Apache サーバーのさまざまな設定オプションを説明します。 もちろん、その設定方法はほぼすべての UNIX システムに拡張できます。

Apache には設定用のパラメータが多数用意されていますが、基本的にこれらのパラメータは非常に明確であり、Apache サーバーは変更せずに実行できます。ただし、Apache サーバーのパフォーマンスを調整し、特定の機能のサポートを追加する必要がある場合は、これらの設定パラメーターの意味を理解する必要があります。

オペレーティング システムのパフォーマンス調整に加えて、Apache サーバー自体のデフォルト設定は決して最も最適化されて効率的ではなく、ほぼすべての設定に適応する必要があることに注意してください。オペレーティング システムの種類とハードウェアの種類が異なる場合、マルチプラットフォーム ソフトウェアは、特定のプラットフォームおよび特定のハードウェアに最適なデフォルト構成を提供できません。したがって、Apache を使用する場合はパフォーマンスのチューニングが不可欠です。

この記事のディレクトリへのクイックアクセス:

httpd.conf の基本構成とパフォーマンス最適化の関係

その他の高速化方法

付録 1 mod_gzip を使用した Apache の高速化

httpd.conf の基本構成とパフォーマンスの最適化の関係

httpd.conf では、httpd デーモンの実行時に必要ないくつかのパラメーターが最初に定義されます。動作方法と動作環境を決定するために実行します。 以下は、httpd.conf での構成パラメータの定義と、さまざまな構成および最適化の方法を段階的に説明したものです:

(最適化への近道はありません。最初に各構成の意味を理解する必要があります) )

ServerType スタンドアロン

ServerType はサーバーの起動モードを定義します。デフォルト値はスタンドアロンです。httpd サーバーは単独で起動され、ホストに常駐します。接続リクエストを監視します。 Linux では、Web サーバーは起動ファイル /etc/rc.d/rc.local/init.d/apache で自動的に起動されます。この方法が推奨される設定です。

Apache サーバーを起動するもう 1 つの方法は、スーパー サーバー inetd を使用して接続要求を監視し、サーバーを起動する inet メソッドです。 inetd 起動モードを使用する必要がある場合は、この設定に変更し、/etc/rc.d/rc.local/init.d/apache ファイルをブロックし、/etc/inetd.conf を変更して inetd を再起動する必要があります。 Apache は inetd から起動できます。

2 つの方法の違いは、独立した方法ではサーバー自体が独自の起動プロセスを管理するため、サーバーの複数のコピーを起動時にすぐに起動でき、各コピーは接続リクエストが発生すると、子プロセスを生成せずにすぐに処理できるため、顧客のブラウザからのリクエストに高速に応答し、パフォーマンスが向上します。 inetd 方式では、接続要求を検出した後でのみ inetd が http サーバーを開始する必要があるため、応答が遅くなり効率は低くなりますが、ポートが存在する場合に Web サーバーが占有するリソースが節約されます。接続要求はありません。したがって、inetd メソッドは、時々アクセスされ、アクセス速度を必要としないサーバーでのみ使用されます。実際、inetd メソッドは http のバーストおよびマルチ接続の特性には適していません。ページに複数の画像が含まれる可能性があり、訪問者数が少ない場合でも、各画像によって接続要求が発生するためです。多くの場合、これは inetd のパフォーマンスによって制限され、inetd によって開始される他のサーバー プログラムに影響を与える可能性もあります。

ServerRoot "/usr/local"

ServerRoot は、httpd デーモンの実行ディレクトリを指定するために使用されます。httpd が起動すると、現在のディレクトリが自動的に変更されます。したがって、設定ファイルで指定されたファイルまたはディレクトリが相対パスである場合、実際のパスは、この ServerRoot で定義されたパスの下にあります。

httpd は同時ファイル操作を実行することが多いため、ファイル操作が競合しないようにロックを使用する必要があります。NFS ファイル システムのファイル ロック機能は限られているため、このディレクトリはローカル ディスクである必要があります。ファイル システムと NFS ファイル システムは使用しないでください。

# LockFile /var/lock/httpd.lock

LockFile パラメータは、httpd デーモンのロック ファイルを指定します。通常、このパラメータを設定する必要はありません。 . ApacheサーバーはServerRoot以下のパスで自動的に動作します。ただし、ServerRoot が NFS ファイル システムである場合は、読み取りおよび書き込み速度を向上させるために、このパラメータを使用してローカル ファイル システム内のパスを指定する必要があります。

PidFile /var/run/httpd.pid

PidFile で指定されたファイルには httpd デーモンのプロセス番号が記録されます。httpd はそれ自体を自動的にコピーできるため、システム システムには複数の httpd プロセスがありますが、最初に開始されるプロセスは 1 つだけです。このプロセスにシグナルを送信すると、すべての httpd プロセスに影響します。 httpd 親プロセスのプロセス番号は、PidFILE で定義されたファイルに記録されます。

ScoreBoardFile /var/run/httpd.scoreboard

httpd は ScoreBoardFile を使用してプロセスの内部データを維持するため、通常は、そうでない限りこのパラメータを変更する必要はありません。複数の Apache サーバーが 1 台のコンピューター上で実行されている場合、各 Apache サーバーは独立した設定ファイル htt pd.conf を必要とし、異なる ScoreBoardFile を使用します。

#ResourceConfig conf/srm.conf

#AccessConfig conf/access.conf

ResourceConfig と AccessConfig の 2 つのパラメーターは、次の目的で使用されます。 srm.conf および access.conf 設定ファイルは、Apache の古いバージョンと互換性があります。互換性が必要ない場合は、対応する設定ファイルを /dev/null として指定できます。これは、他に設定ファイルがなく、すべての設定オプションの保存に 1 つのファイル httpd.conf のみが使用されることを示します。

タイムアウト 300

タイムアウトは、クライアント プログラムとサーバー間の接続のタイムアウト間隔を定義します。この時間間隔 (秒) を超えると、サーバーはクライアントの接続を切断します。サーバーの負荷が高い場合は、この数を適切に減らすことができます。

KeepAlive On

HTTP 1.0 では、1 つの接続は 1 つの HTTP リクエストのみを送信でき、KeepAlive パラメーターは HTTP の 1 つの接続と複数の送信機能をサポートするために使用されます。そのため、複数の HTTP リクエストを 1 つの接続で渡すことができます。

MaxKeepAliveRequests 100

MaxKeepAliveRequests は、1 つの接続で実行できる HTTP リクエストの最大数です。この値を 0 に設定すると、1 つの接続内で無制限の数の転送リクエストがサポートされます。実際、1 回の接続で多すぎるページを要求するクライアント プログラムはなく、通常、接続はこの上限に達する前に完了します。 この数値を適切に調整して最大速度を得ることができます。

KeepAliveTimeout 15

KeepAliveTimeout は、サーバーがリクエストを完了したが、次のリクエストを受信して​​いない場合、複数のリクエスト送信間の時間をテストします。間隔がこのパラメータで設定された値を超えると、サーバーは切断されます。アイドル状態の接続をできるだけ早く解放するために、この値を適切に減らすことができます。ただし、小さすぎると、ほとんどのクライアントが再接続する必要があり、CPU 時間が消費されます。

MinSpareServers 5

MaxSpareServers 10

サブプロセスを使用して HTTP リクエストを処理する Web サーバー上。サブプロセスは最初に行う必要があるためクライアントのリクエストを処理するために生成されるため、応答時間は少し遅れます。ただし、Apache サーバーは、この問題を解決するために、システム内に常駐する複数のアイドル サブプロセスを事前に生成する特別なテクノロジーを使用しており、リクエストが発生すると、これらのアイドル サブプロセスがすぐに処理に使用されます。子プロセスの生成による遅延がないこと。動作中にクライアント要求の数が増加すると、開始される子プロセスの数も増加します。ただし、これらのサーバー コピーは HTTP 要求の処理後すぐに終了せず、次の要求を待機するコンピューター内に残ります。ただし、予備のサブプロセスのコピーの数は減らさずに増やすことはできません。処理タスクを持たない予備のサブプロセスが多すぎると、サーバーの処理能力を占有してしまうため、適切な数を維持するには予備のコピーの数を制限する必要があります。両方をタイムリーに処理できるため、無駄なプロセスの数も削減できます。

したがって、パラメータ MinSpareServers を使用してアイドル状態の子プロセスの最小数を設定し、パラメータ MaxSpareServers を使用してアイドル状態の子プロセスの最大数を制限すると、過剰なサーバー プロセスのコピーが終了します。サーバーのパフォーマンスが高く、頻繁にアクセスされる場合は、これら 2 つのパラメーターの設定を増やす必要があります。高負荷のプロフェッショナル Web サイトの場合、これら 2 つの値はシステムでサポートされるサーバー レプリカの最大数とほぼ同じであり、不必要なレプリカの終了も減らす必要があります。

たとえば、システムの負荷が高い場合、次のように検出できます:

[iaspec@www iaspec]$ ps -ef|grep apache|wc

55 .. ..

[iaspec@www iaspec]$

これは、高負荷下で 55 個のサブプロセスが実行されていることを示しています。このサーバーが WEB 専用サーバーの場合は、次のようにする必要があります。速度テストの結果に応じて、これら 2 つの値を個別に設定することを検討してください。50、60、または 40、70 です。

StartServers 5

StartServers パラメーターは、httpd の開始時に開始される子プロセスのコピーの数を設定するために使用されます。このパラメーターは、上で定義した MinSpareServers パラメーターと MaxSpareServers パラメーターに関連します。 、両方 サーバーの応答速度を向上させるためにアイドル状態のサブプロセスを開始するために使用されます。このパラメータは、最初の 2 つの値の間の値に設定する必要があります。MinSpareServers より小さくても、MaxSpareServers より大きくても意味がありません。

MaxClients 150

一方で、サーバーの能力には結局のところ限界があり、無制限の数の接続要求を同時に処理することは不可能です。そのため、パラメータ Maxclients は、サーバーでサポートされる同時アクセス クライアントの最大数を指定するために使用されます。この値が大きすぎると、システムがビジー状態になったときに、あまりにも多くのクライアントにサービスを提供するために、非常に多くのプロセス間で切り替える必要が生じます。各クライアントへの応答が遅くなり、全体の効率が低下します。この値を小さい値に設定すると、システムがビジー状態のときに一部のクライアント接続要求が拒否されます。サーバーのパフォーマンスが高い場合は、この値の設定を適切に増やすことができます。プロフェッショナルな Web サイトでは、サーバーの効率を向上させる戦略を使用する必要があるため、このパラメータがハードウェア自体の制限を超えることはできません。アクセス拒否が頻繁に発生する場合は、サーバー ハードウェアをアップグレードする必要があることを意味します。クライアントのブラウザの応答速度をあまり気にしない場合、または接続を拒否するより応答速度が遅いほうが良いと考えられる場合は、このパラメータをハードウェア条件を少し超えて設定することもできます。

では、適切な値はどれくらいでしょうか?パフォーマンス要件が高い場合は、次の方法を使用して、このパラメータの構成方法を決定できます。

まず、可能な最大同時接続数を見積もるか、ps -ef|grep apache|wc コマンドを使用して高負荷時の最大プロセス数を測定します。通常、MaxClients はこの値の約 2 倍になります。 。高負荷時の現在の Web サイトのアクセス速度は許容できるが、サービス妨害がある場合は、このパラメータを増やす必要があります。サービス妨害はないが、アクセス速度が遅い場合は、この値を減らす必要があります。

このパラメータは、MinSpareServers と MaxSpareServers の設定を同時に制限し、このパラメータの設定よりも大きくすることはできません。

負荷の高いマシンの場合、これを行うだけでは十分ではありません。

Apache がリクエストに対してオープンできるプロセスの最大数は 256 で、MaxClients の制限は 256 です。ユーザーが多すぎる場合、ユーザーには「応答を待っています...」しか表示されません。そして、次のプロセスが利用可能になるまで待ちます。プロセスが出現します。この最大数は Apache プログラムによって決定されます。NT バージョンには 1024 が指定できますが、Unix バージョンには 256 しか指定できません。これは include/httpd.h

:

#ifndef で確認できます。 HARD_SERVER_LIMIT

#ifdef WIN32

#define HARD_SERVER_LIMIT 1024

#else

#define HARD_SERVER_LIMIT 256

#endif

#endif

システムをコンパイルする前に 1024 に調整できます。 httpd.conf内の対応する設定も忘れずに変更してください。

MaxRequestsPerChild 30

サブプロセスを使用してサービスを提供する Web サービスの一般的な方法は、サブプロセスが接続を提供することです。接続が子プロセスを生成および終了するためにシステム操作を必要とするたびに、これらの追加プロセスがコンピュータの処理能力を大量に占有することになります。したがって、子プロセスが複数の接続リクエストを処理できるようにするのが最善の方法であり、Apache は接続の完了後に子プロセスを終了せずにこの方法を採用します。ただし、次のサービス要求を待機するシステム内に留まるため、パフォーマンスが大幅に向上します。

ただし、子プロセスは処理中にメモリの申請と解放を継続的に行う必要があるため、回数が多すぎるとメモリのガベージが発生し、システムの安定性とシステムの効率的な使用に影響します。リソース。 。したがって、コピーが一定数のリクエストを処理した後、サブプロセスのコピーを終了し、元の httpd プロセスからクリーン コピーをコピーできるため、システムの安定性が向上します。このように、各子プロセスが処理するサービスリクエストの数は MaxRequestPerChild で定義されます。デフォルトの設定値は 30 ですが、これは安定性の高い Linux システムにとっては控えめすぎます。これを 0 に設定すると、各コピーの無制限のサービス処理がサポートされます。

#Listen 3000

#Listen 12.34.56.78:80

#BindAddress *

Listen パラメーターはサーバーを指定できます監視に加えて、標準ポート 80 に加えて、他のポート上の HTTP リクエストも監視されます。システムは同時に複数の IP アドレスを持つことができるため、サーバーが特定の BindAddress< /B> の IP アドレスに対する HTTP リクエストのみをリッスンするように指定することもできます。これが構成されていない場合、サーバーはすべての IP のリクエストに応答します。

サーバーが 1 つの IP アドレスに対するリクエストにのみ応答するように BindAddress パラメータが使用されている場合でも、拡張 Listen パラメータを使用することで HTTP デーモンが他の IP アドレスに対するリクエストに応答するようにすることができます。 。このときの Listen パラメータの使用方法は、上記の 2 番目の例と同じです。このより複雑な使用法は、主に仮想ホストをセットアップするために使用されます。その後、VirtualHost パラメータを使用して、異なる IP を持つ仮想ホストを定義できます。ただし、この使用法は、以前の HTTP 1.0 標準で仮想ホストを設定する方法であり、実際にはあまり役に立ちません。 HTTP 1.1 では、単一の IP アドレスと複数のドメイン名を持つ仮想ホストのサポートが追加され、仮想ホストの設定がより意味のあるものになりました。

モジュール変数

LoadModule mime_magic_module libexec/apache/mod_mime_magic.so

LoadModule info_module libexec/apache/mod_info.so

LoadModule speling_module libexe c /apache/mod_speling.so

LoadModule proxy_module libexec/apache/libproxy.so

LoadModule rewrite_module libexec/apache/mod_rewrite.so

LoadModule anon_auth_module libexec/apache/mod_auth_anon。 so

LoadModule db_auth_module libexec/apache/mod_auth_db.so

LoadModule Digest_module libexec/apache/mod_digest.so

LoadModule cern_meta_module libexec/apache/mod_cern_meta.so

LoadModuleexpires_module libexec/apache/mod_expires.so

LoadModule headers_module libexec/apache/mod_headers.so

LoadModule usertrack_module libexec/apache/mod_usertrack.so

LoadModule unique_id_module libexec /apache/mod_unique_id.so

ClearModuleList

AddModule mod_env.c

AddModule mod_log_config.c

AddModule mod_mime_magic.c

AddModule mod_mime.c

AddModule mod_negotiation.c

AddModule mod_status.c

AddModule mod_info.c

AddModule mod_include.c

AddModule mod_autoindex.c

AddModule mod_dir.c

AddModule mod_cgi.c

AddModule mod_asis.c

AddModule mod_imap.c

AddModule mod_actions.c

AddModule mod_speling.c

AddModule mod_userdir.c

AddModule mod_proxy.c

AddModule mod_alias.c

AddModule mod_rewrite.c

AddModule mod_access.c

AddModule mod_auth.c

AddModule mod_auth_anon.c

AddModule mod_auth_db.c

AddModule mod_digest.c

AddModule mod_cern_meta.c

AddModule mod_expires.c

AddModule mod_headers.c

AddModule mod_usertrack.c

AddModule mod_unique_id.c

AddModule mod_so.c

AddModule mod_setenvif.c

Apache サーバーの重要な機能は、そのモジュール構造です。これは、新しい機能を反映しているだけではありません。コンパイル中に新しいモジュールを介して機能を追加でき、不要なモジュールをロードすることなくモジュールを http サービス プログラムに動的にロードできます。Apache の動的にロードされるモジュールを使用するには、Load Module パラメータと AddModule パラメータを設定するだけで済みます。ただし、DSO 機能を使いこなすのはまだ簡単ではありません。ここで設定を変更すると、サーバーが正常に起動できなくなる可能性があります。したがって、サーバーが提供する機能を増減したくない場合は、ここでの設定を変更しないでください。

上記のリストは、Linux のデフォルトの Apache サーバーでサポートされているモジュールを示しています。実際には、多くのモジュールは不要であり、不要なモジュールはメモリにロードされません。モジュールは Apache サーバーに静的に接続することも、動的にロードすることもできます。これは、Apache のデフォルトのアプローチではなく、すべての Apache 機能を動的にロード可能なモジュールにコンパイルすることであり、同時にパフォーマンスをほとんど犠牲にすることはありません。

したがって、動的にロードする機能は依然としてパフォーマンスにわずかな影響を与えるため、Apache を再コンパイルし、必要な関数を Apache サーバーにコンパイルすることで、システムをクリーンかつ効率的にすることができます。わずかな改善もあります。通常、この目的のためだけに Apache を再コンパイルする必要はありません。他の機能を追加するために Apache を再コンパイルする必要がある場合は、他のモジュールを追加して、すべてのモジュールを Apache サーバーに静的に接続することをお勧めします。

これらのモジュールは /usr/local/apache/modules/ ディレクトリに配置され、各モジュールは Apache サーバーの機能に対応します。各モジュールの機能を詳しく説明するにはかなりのスペースが必要です。より重要な機能については、後ほど対応する箇所で説明します。

#ExtendedStatus On

Apache サーバーは、テスト ツールを使用してテストするときに、この ExtendedStatus パラメータをオンにすると、独自の実行ステータスを報告できます。サーバーは、より包括的な動作ステータス情報を報告します。

メインサーバー設定

Apache サーバーは、サーバーを提供するために、さまざまなパラメーターを使用して自身を定義するためのさまざまな設定を必要とします。ウェブサービス。仮想ホストを使用する場合、ここでの設定は、仮想ホストの定義で上書きされる設定（一部の設定を再定義する必要があります）に加えて、仮想ホストのデフォルトの設定でもあります。

ポート 80

ポートは、スタンドアロン モードで httpd デーモンによって使用されるポートを定義します。標準ポートは 80 です。このオプションは、スタンドアロン モードで起動されたサーバーにのみ有効です。inetd モードで起動されたサーバーの場合、使用するポートは inetd.conf で定義されます。

Unix でポート 80 を使用するには root 権限が必要です。セキュリティ上の理由から、一部の管理者は、httpd サーバーにセキュリティ上の脆弱性が存在するはずがないため、この方法でサーバーを起動するのに通常のユーザー権限を使用することを好みます。 80 および 1024 より小さい他のポートは使用できませんが、httpd を起動するには 1024 より大きいポートを使用する必要があります。通常、8000 または 8080 もよく使用されます。 Apache httpd サーバー自体は、root 権限でポート 80 を開き、通常のユーザーとして実行するように変更できるため、このセキュリティ問題を考慮する必要がありません。ただし、一般のユーザーも独自の WWW サーバーをインストールして構成したい場合は、1024 より大きいポートを使用する必要があります。

UserEveryone

Group nogroup

User と Group の設定は、Apache がポートを開いた後、Apache のセキュリティを保証します。これら 2 つのオプションを実行するためにユーザーとグループの権限が設定されているため、サーバーのリスクが軽減されます。このオプションは、スタンドアロン モードでのみ使用されます。Inetd モードでは、inetd.conf で Apache を実行するユーザーを指定します。 ID を変更するにはサーバーが setuid() 操作を実行する必要があるため、初期プロセスには root 権限が必要です。root 以外のユーザーを使用して Aapche を起動する場合、この構成は機能しません。

デフォルト設定は、nobody および nogroup です。このユーザーとグループはシステム内のファイルを所有していないため、サーバー自体とサーバーによって開始された CGI プロセスにはファイル システムを変更する権限がありません。 。たとえば、CGI を実行して Unix と対話するために、サーバーはサーバー上のファイルにアクセスする必要がある場合もあります。nobody と nogroup がまだ使用されている場合、誰にも属していないファイルがシステムに表示され、システムに悪影響を及ぼします。システム セキュリティ。他のプログラムも、nobody および nogroup のアクセス許可を使用して特定の操作を実行するため、これらの none が所有するファイルにアクセスする可能性があり、セキュリティ上の問題が発生します。通常、Web サービスに特定のユーザーとグループを設定し、ここでユーザーとグループの設定を変更します。

ServerAdmin you@your.address

おそらく、構成ファイル内で変更する必要があるのは ServerAdmin だけです。これは、管理者の電子メール アドレスを構成するために使用されます。 HTTP サービス エラーが発生した場合、WWW サーバーの情報がブラウザに返されるため、Web ユーザーと管理者は管理者にエラーを報告できます。 WWW サーバーの管理者としてサーバー上の Web マスターを使用し、Web マスターに送信されたメールをメール サーバーのエイリアス機構を介して実際の Web 管理者に送信するのが一般的です。

#ServerName new.host.name

デフォルトでは、この ServerName パラメーターを指定する必要はありません。サーバーは名前解決を通じて自動的に独自の名前を取得します。 process ですが、サーバーの名前解決に問題がある場合 (通常は間違った逆解決)、または正式な DNS 名がない場合は、ここで IP アドレスを指定することもできます。 ServerName が正しく設定されていない場合、サーバーは正常に起動できません。

通常、Web サーバーは複数の名前を持つことができ、クライアント ブラウザはこれらすべての名前または IP アドレスを使用してサーバーにアクセスできますが、仮想ホストが定義されていないと、サーバーは常に「応答への応答」で終了します。ブラウザに正式名を入力してください。 ServerName は、Web サーバー自体が認識する正式な名前を定義します。たとえば、サーバーの名前 (タイプ A は DNS で定義されます) は、記憶の便宜上、エイリアス (CNAME) です。このように、クライアントのブラウザがリクエストの送信にどの名前を使用しても、サーバーは常にそれを通知します。クライアントプログラムはexample.org.cnです。通常はこれで問題ありませんが、いつかサーバーを別のコンピュータに移動する可能性があり、DNS の www エイリアス設定を変更するだけで移行作業が完了することを考えると、お客様には Linux レコードを使用してほしくないのです。このサーバーのアドレスを指定するには、ServerName を使用してサーバーの正式名を再指定する必要があります。

DocumentRoot "/www/"

DocumentRoot は、このサーバーによって公開されたハイパーテキスト ドキュメントが保存されるパスを定義します。クライアント プログラムによって要求された URL がこれにマッピングされます。ディレクトリの下にあるWebファイル。 URL で同じ相対ディレクトリ名が使用されている限り、このディレクトリの下のサブディレクトリ、およびシンボリック リンクを使用して指定されたファイルやディレクトリにブラウザからアクセスできます。

シンボリック リンクは、論理的にはルート ドキュメント ディレクトリの下に配置されますが、実際にはコンピュータ上の任意のディレクトリに配置できるため、クライアント プログラムはこれらのルート ドキュメント ディレクトリの外部のディレクトリにアクセスできることに注意してください。柔軟性は向上しますが、セキュリティは低下します。 Apache は、シンボリック リンクのサポート機能をオンまたはオフにするためのディレクトリ アクセス制御に FollowSymLinks オプションを提供します。

オプション FollowSymLinks

AllowOverride なし

Apache サーバーはディレクトリのドキュメント アクセス制御を実行できます。ただし、アクセス制御は 2 つの方法で実現できます。 1 つは、設定ファイル httpd.conf (または access.conf) でディレクトリごとに設定する方法です。もう 1 つは、アクセス制御ファイルをディレクトリごとに設定する方法です。通常、アクセス制御ファイル名は です。どちらの方法もブラウザのアクセスを制御するために使用できますが、構成ファイルを使用する方法は変更のたびに httpd デーモンを再起動する必要があるため、主にサーバー システム全体のセキュリティ制御戦略を構成するために使用されます。各ディレクトリの .htaccess ファイルを使用して特定のディレクトリにアクセス制御を設定する方が、より柔軟で便利です。

Directory ステートメントは、ディレクトリのアクセス制限を定義するために使用されます。ここでは、ディレクトリのアクセス制限を定義するための標準構文を確認できます。上記の例の設定は、システムのルート ディレクトリに対するものであり、シンボリック リンクを許可するオプション FollowSymLinks が設定されており、このディレクトリ内のアクセス制御ファイルがここでの構成を変更できないことを示すために使用されます。また、このディレクトリ内の対応するアクセス制御ファイルを表示する必要がないことも意味します。

ディレクトリに対する Apache のアクセス制御設定は下位のディレクトリに継承できるため、ルート ディレクトリの設定は下位のディレクトリに影響します。 AllowOverride None の設定により、Apache サーバーはルート ディレクトリ内のアクセス コントロール ファイルをチェックする必要がなく、httpd.conf (または access.conf) までは次のディレクトリ内のアクセス コントロール ファイルをチェックする必要もないことに注意してください。 ) には、Alloworride が指定されており、アクセス制御ファイルの閲覧が許可されています。 Apache はディレクトリ アクセス制御に継承方式を採用しているため、ルート ディレクトリからのアクセス制御ファイルの表示が許可されている場合、Apache はアクセス制御ファイルをレベルごとに表示する必要があり、これがシステム パフォーマンスに影響します。デフォルトでは、ルート ディレクトリのこの機能はオフになっており、Apache は httpd.conf で指定されたディレクトリから下方向に検索することになり、検索レベルの数が減り、システム パフォーマンスが向上します。したがって、システム ルート ディレクトリにAllowOverride Noneを設定すると、システムのセキュリティに役立つだけでなく、システムのパフォーマンスにも有益です。

オプション インデックス FollowSymLinks

AllowOverride なし

順序許可、拒否

ここで定義されているすべての

から許可システムがドキュメントを外部に公開するディレクトリのアクセス設定です。構成ファイルのディレクトリ設定とユーザー ディレクトリのセキュリティ制御ファイルの間の関係を定義するために、さまざまな AllowOverride オプションを設定します。特性を定義するために、Options オプションが使用されます。ディレクトリの。

アクセス制限は、各ディレクトリ配下の設定ファイルとアクセス制御ファイルで設定できます。設定ファイルは管理者が設定し、各ディレクトリ配下のアクセス制御ファイルはディレクトリの所有者が設定します。したがって、管理者は、ディレクトリの所有者が設定ファイルでシステムの設定をオーバーライドできるかどうかを指定できます。これは、AllowOverride パラメーターを使用して設定する必要があります。通常、設定できる値は次のとおりです。 ロールに対する AllowOverride 設定の影響。各ディレクトリのアクセス制御ファイルの [All] はデフォルト値であり、アクセス制御ファイルがシステム構成をオーバーライドできます。

なし サーバーはアクセス制御ファイルの設定を無視します。

Options では、制御ファイルの Options パラメータを使用して定義できるディレクトリ内のオプションにアクセスできます。

FileInfo を使用すると、AddType などのパラメーター設定をアクセス制御ファイルで使用できます。

AuthConfig を使用すると、アクセス制御ファイルで各ユーザーの AuthName、AuthType、およびその他の認証メカニズムを使用できるようになり、ディレクトリ所有者は、アクセスするクライアントの IP アドレスと IP アドレスを使用してディレクトリを保護できます。保護するディレクトリの名前の制限。

各ディレクトリには特定の属性があります。オプションを使用して、このディレクトリ内の一部のアクセス機能設定を制御できます。一般的に使用される機能オプションは次のとおりです。

オプション設定 サーバー機能設定。

All すべてのディレクトリ属性が有効になっており、これがデフォルトの状態です。

なし すべてのディレクトリ属性は効果がありません。

FollowSymLinks では、シンボリック リンクの使用が許可されます。これにより、ブラウザがドキュメント ルート (DocumentRoot) の外部にあるドキュメントにアクセスできるようになります。 SymLinksIfOwnerMatch シンボリック リンクの目的が同じユーザーによって所有されている場合のみシンボリック リンク自体としてアクセスが許可されるため、この設定によりセキュリティが追加されます。

ExecCGI を使用すると、このディレクトリで CGI プログラムを実行できます。 インデックスを使用すると、ブラウザがこのディレクトリ内のすべてのファイルのインデックスを生成できるようになります。ディレクトリにあるファイルのリストをブラウザに送信できます

さらに、上記の例では、制限で使用される Order、Allow、Deny などのパラメータも使用します。ステートメントを使用してブラウザのドメイン名と IP アドレスを決定し、アクセスを制御する方法。 Order は、Allow と Deny が処理される順序を定義し、Allow と Deny は名前または IP のアクセス制御設定を実行します。これは、すべてのクライアントが制限なくこのディレクトリにアクセスできることを意味します。

UserDir public_html

Linux 上で Apache サーバーを実行している場合、このコンピュータ上のすべてのユーザーは http:// の形式で独自の Web ページ パスを持つことができます。 example.org.cn/~user では、チルダ記号とユーザー名を使用して、ユーザー自身の Web ディレクトリにマップします。マッピング ディレクトリはユーザーの個人ホーム ディレクトリの下のサブディレクトリであり、その名前は UseDir パラメータを使用して定義されます。デフォルトは public_html です。正式なユーザーに Web サービスを提供したくない場合は、UserDir のパラメーターとして DISABLED を使用してください。

#AllowOverride FileInfo AuthConfig Limit

# Options MultiViews Indexes SymLinksIfOwnerMatch includesNoExec

# 順序許可、拒否

# すべてから許可

# 注文拒否,許可

# すべて拒否

ここでは、ディレクトリの別の使用法を示します。つまり、単純なパターン マッチング方法を使用して、さまざまなターゲットを指定できます。ディレクトリの下のサブディレクトリは、アクセス制御権限を定義します。この設定では、Apache サーバーが各パスで追加の処理を実行する必要があり、サーバーのパフォーマンスが低下するため、このアクセス制限はデフォルトではオンになっていません。

ここでは、別のステートメント Limit を参照します。Limit ステートメントは、GET や POST など、さまざまなサーバーでサポートされているリクエスト メソッドのアクセス制御を設定するために使用されます。さまざまなリクエストメソッドにアクセス制限を設定します。通常、GET、POST、HEAD の 3 つのリクエスト メソッドを有効にし、他のリクエスト メソッドをブロックしてセキュリティを強化できます。 Limit ステートメントでは、Order、Allow、Deny を使用して、ドメイン名と IP を制限することができます。ただし、ドメイン名は後ろから前に照合され、IP アドレスは前から照合されます。後ろに。

DirectoryIndexindex.html

多くの場合、URL にはドキュメントの名前が指定されず、ディレクトリ名のみが指定されます。その後、Apache サーバーはこのディレクトリ内の DirectoryIndex で定義されたファイルを自動的に返します。もちろん、複数のファイル名を指定することもでき、システムはこのディレクトリ内で順番に検索します。 DirectoryIndex で指定されたすべてのファイルが存在しない場合、Apache サーバーはシステム設定に基づいてこのディレクトリ内のすべてのファイルのリストを生成し、ユーザーに選択を提供できます。このとき、サーバーがディレクトリ リストを生成できるように、ディレクトリのアクセス制御オプションのインデックス オプション (オプション インデックス) をオンにする必要があります。オンにしないと、Apache がアクセスを拒否します。

AccessFileName .htaccess

AccessFileName は、各ディレクトリ内のアクセス制御ファイルのファイル名を定義します。デフォルトは .htaccess です。このファイルを変更することで変更できます。ディレクトリのアクセス制御制限。

順番許可、拒否

すべて拒否

ディレクトリに対するアクセス制御に加えて、ファイルに基づいたアクセス制御も設定できます。 File ステートメントのタスクです。 File ステートメントを使用すると、ファイルがどのディレクトリにあっても、名前が一致する限り、対応するアクセス制御を受け入れる必要があります。このステートメントはシステム セキュリティにとって重要です。たとえば、上記の例では、すべてのユーザーが .htaccess ファイルにアクセスすることがブロックされ、顧客が .htaccess 内の重要なセキュリティ情報を取得できなくなります。

#CacheNegotiatedDocs

デフォルトでは、プロキシ サーバーが Web ページをキャッシュするかどうかを Apache サーバーとネゴシエートする場合、Apache は否定的な応答を返し、その要求を要求しません。プロキシ サーバーによってキャッシュされる Web ページ。ただし、これではプロキシ サーバーを効果的に利用できないため、プロキシ サーバーが Web ページをキャッシュできるように CacheNegotiatieDocs オプションを設定できます。ただし、このオプションが設定されていない場合でも、一部のプロキシ サーバーは (または設定を調整することで) Web ページをキャッシュできます。

UseCanonicalName On

この UseCanonicalName を開くのは Web サーバーの標準的な方法です。これは、クライアントから送信されるほとんどのリクエストがこのサーバーへの参照であるため、サーバーは ServerName を使用できるためです。 Portオプションの設定内容で完全なURLを構築し、ブラウザが正規URLを取得できるようにクライアントに応答します。このパラメータが Off に設定されている場合、Apache はクライアント リクエストから取得したサーバー名とポート値を使用して URL を再構築します (この情報は、HTTP 1.1 をサポートするクライアントからのリクエストに含まれます)。

TypesConfig /etc/mime.types

TypeConfig は、さまざまな MIME タイプ データを保存するファイル名を設定するために使用されます。Linux のデフォルト設定は /usr/local です。 /apache/etc/mime.types または /etc/mime.types。

DefaultType text/plain

Web サーバーがドキュメントのデフォルトのタイプを判断できない場合 (通常、ドキュメントで非標準のサフィックスが使用されていることを意味します)、サーバーは DefaultType を使用します。 ドキュメントをクライアント ブラウザに送信するための MIME タイプを定義します。ここでの設定は text/plain です。この設定の問題は、サーバーがドキュメントの MIME を判別できない場合、ほとんどの場合、ドキュメントはバイナリ ドキュメントになりますが、text/plain 形式で送り返されると、ブラウザは内部的にそれを開きますが、保存を促すメッセージは表示されません。したがって、ブラウザーがユーザーに保存を促すように、この設定を application/octet-stream に変更することをお勧めします。

MIMEMagicFile /usr/share/magic

Apache は、ファイルの拡張子からファイルの MIME タイプを判断することに加えて、ファイルのいくつかの特性をさらに分析して、ファイルの真の MIME タイプを判断します。この機能は mod_mime_magic モジュールによって実装されており、解析や判断のためにさまざまな MIME タイプの特性を記録したファイルが必要です。上記の設定は条件文です。このモジュールがロードされる場合、対応するフラグ ファイル マジックの場所を指定する必要があります。

HostnameLookups Off

通常、サーバーは接続時にクライアントの IP アドレスのみを取得できます。クライアントのホスト名を取得したい場合は、ログを記録して CGI に提供するために使用できます。プログラムを使用するには、この HostnameLookups オプションを使用してオンに設定し、DNS 逆引き参照機能を有効にする必要があります。ただし、これによりサーバーはクライアント要求ごとに DNS クエリを実行することになり、システムのオーバーヘッドが増加し、応答が遅くなります。そのため、デフォルト設定では、このオプションをオフにするために [オフ] が使用されます。このオプションをオフにすると、サーバーはクライアントのホスト名を取得せず、クライアントのログを記録するために IP アドレスのみを使用できます。

ErrorLog /var/log/httpd-error.log

ログレベル warn

LogFormat "%h %l %u %t "%r" %> ;s %b "%{Referer}i" "%{User-Agent} "" 結合

LogFormat "%h %l %u %t "%r" %>s %b" common

ログ形式 "%{Referer}i -> %U" リファラー

ログ形式 "%{User-agent}i" エージェント

#CustomLog /var/log/httpd -access.log 共通

#CustomLog /var/log/httpd-referer.log リファラー

#CustomLog /var/log/httpd-agent.log エージェント

CustomLog /var/log/httpd-access.log を組み合わせた

これは、サーバー エラー レコードの形式を定義し、ErrorLog と LogLevel は異なるエラー ログ ファイルとそのレコードの内容を定義します。

システム アクセス ログの場合、ログの場所を定義するためにデフォルトで CustomLog パラメータが使用され、すべてのアクセス ログが 1 つのファイルに配置されることを指定します。アクセス ログは、CustomLog で異なるログ タイプを指定することによって、別のログ ファイルに配置することもできます。common表示普通的对单页面请求访问记录，referer表示每个页面的引用记录，可以看出一个页面中包含的请求数，agent表示对客户机的类型记录，显然可以将现有的combined 定义的设置行注释掉，并使用common、referer和agent作为CustomLog的参数，来为不同种类的日志分别指定日志记录文件。

显然，LogFormat是用于定义不同类型的日志进行记录时使用的格式， 这里使用了以%开头的宏定义，以记录不同的内容。 如果这些参数指定的文件使用的是相对路径，那么就是相对于ServerRoot的路径。

ServerSignature On

一些情况下，例如当客户请求的网页并不存在时，服务器将产生错误文档，缺省情况下由于打开了 ServerSignature选项，错误文档的最后一行将包含服务器的名字、Apache的版本等信息。有的管理员更倾向于不对外显示这些信息，就可以将这个参数设置为Off，或者设置为Email，最后一行将替换为对 ServerAdmin 的Email提示。

Alias /icons/ "/www/icons/"

Options Indexes MultiViews

AllowOverride None

Order allow,deny

Allow from all

Alias パラメータは、URL をサーバー ファイル システム内の実際の場所に直接マッピングするために使用されます。ただし、Alias を使用して定義されたパスは、対応するディレクトリに直接マッピングされます。以下の DocumentRoot に移動する代わりに。したがって、Alias を使用して、一般的に使用されるさまざまなアイコンを保存するアイコン パスなど、一部のパブリック ファイルのパスをマッピングできます。このように、シンボリック リンクの使用に加えて、エイリアス マッピングを使用して、ドキュメント ルート ディレクトリ (DocumentRoot) の外側のディレクトリにもブラウザからアクセスできます。 マップされたパスを定義した後、Directory ステートメントを使用してアクセス制限を設定する必要があります。

ScriptAlias /cgi-bin/ "/www/cgi-bin/"

AllowOverride なし

オプション なし

順序許可,deny

Allow from all

ScriptAlias も URL パスのマッピングに使用されますが、Alias との違いは、ScriptAlias が URL パスのマッピングに使用されることです。 CGI プログラム このパスの下のファイルは CGI プログラムとして定義されており、結果はサーバーからコンテンツが直接返されるのではなく、実行によって取得されます。デフォルトでは、CGI プログラムは仮想パスとして cgi-bin ディレクトリを使用します。

# Redirect old-URI new-URL

Redirect パラメータは、ブラウザがサーバー上の存在しないリソースにアクセスするときに URL を書き換えるために使用されます。その時点で、サーバーは新しい URL をブラウザに返し、この URL からリソースを取得するようにブラウザに指示します。これは主に、場所が変更された後、以前の URL との互換性を維持するために古い URL を使用してドキュメントにアクセスできるようにするために使用されます。

IndexOptions FancyIndexing

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) ) text/*

AddIconByType (IMG,/icons/image2.gif) image/*

AddIconByType (SND,/icons/sound2.gif) audio/*

AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe

AddIcon /icons/binhex.gif .hqx

AddIcon /icons/tar.gif .tar

AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv

AddIcon /icons/compressed.gif 。 Z .z .tgz .gz .zip

AddIcon /icons/a.gif .ps .ai .eps

AddIcon /icons/layout.gif .html .shtml .htm .pdf

AddIcon /icons/text.gif .txt

AddIcon /icons/c.gif .c

AddIcon /icons/p.gif .pl .py

AddIcon /icons/f.gif .for

AddIcon /icons/dvi.gif .dvi

AddIcon /icons/uuencoded.gif .uu

AddIcon /icons /script.gif .conf .sh .shar .csh .ksh .tcl

AddIcon /icons/tex.gif .tex

AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..

AddIcon /icons/hand.right.gif お読みください

AddIcon /icons/folder.gif ^^ディレクトリ^^

AddIcon /icons/blank.gif ^^BLANKICON^^

DefaultIcon /icons/unknown.gif

#AddDescription "GZIP 圧縮ドキュメント" .gz

#AddDescription "tarアーカイブ" .tar

#AddDescription "GZIP 圧縮 tar アーカイブ" .tgz

ReadmeName README

HeaderName HEADER

IndexIgnore .??* *~ * # HEADER* README* RCS CVS *,v *,t

HTTP 要求の URL が 1 つのアイテムの場合、サーバーはそのアイテム内のインデックス ファイルを返します。ファイルにインデックスを付け、このサーバーがさらにアイテムのファイルリストを表示できるようになった場合、このファイルリストを理解できるようにするために、単一のリストではなく、前のリストが必要です。 IndexOptions FancyIndexing オプションを使用する場合、サーバーが生成するコンテンツ リストでさまざまな種類のドキュメントを参照できます。そのため、各種類のドキュメントは次の AddIconByEncoding を使用します。 、AddIconByTypeおよびAddIcon来どのようなピクチャを使用するかは、MIME のコード、タイプ、およびファイルのその後に応じて決定されます。さらに、サーバーは、ReadmeName と HeaderName で定義されたファイルを使用して、コンテンツを追加します (.html を自動的に追加した後、検出されない場合は、.txt を再使用して検索します)。これらのファイルが見つかった場合は、通常のリスト リストの理解を容易にするために、これらのファイルの内容が最初に表示されます。対応するファイルの略称であり、ここではモード構成によるファイル名が使用されています。

AddEncoding x-compress Z

AddEncoding x-gzip gz

AddEncoding は、一部の MIME タイプに圧縮を使用するように指示するために使用され、これによりブラウザーが圧縮を使用できるようになります。解凍操作を行います。

AddLanguage en .en

AddLanguage fr .fr

AddLanguage .de

AddLanguage da .da

AddLanguage el .el

AddLanguage it .it

LanguagePriority en fr de

HTML ドキュメントには、file1 など、同時に複数の言語バージョンを含めることができます。 .html ドキュメント file1.html.en、file1.html.fr などのさまざまなバージョンを持つことができ、AddLanguage を使用して各言語サフィックスを定義する必要があります。このようにして、サーバーはブラウザとネゴシエートして、さまざまな国の顧客にさまざまな言語バージョンを送信できます。 LanguagePriority はさまざまな言語の優先順位を定義するため、ブラウザーに特別な要件がない場合、file1.html のリクエストに応答するためにさまざまな言語バージョンを使用できます。この国際化機能の実際的な応用例はそれほど多くありません。

#AddType application/x-httpd-php .phtml

#AddType application/x-httpd-php-source .phps

AddType パラメーターは次のとおりです。 specific ファイルの拡張子は MIME タイプを指定し、ここでの設定は mime.types の設定をオーバーライドします。

#AddHandler cgi-script .cgi

AddHandler は、非静的処理タイプを指定するために使用され、ドキュメントを非静的ドキュメント タイプとして定義するために使用されます。 、これは Process である必要があり、処理結果をブラウザーに返します。たとえば、上記のコメントの設定では、.cgi で終わるファイルを cgi-script タイプに設定すると、サーバーは CGI プログラムを起動して処理します。 AliasScript で定義したパスの外で CGI プログラムを実行する必要がある場合は、このパラメータを使用して設定する必要があります。その後、.cgi で終わるファイルが CGI プログラムとして実行されます。 CGI プログラムの実行は、設定ファイル、このディレクトリの .htaccess、およびその親ディレクトリの .htaccess で許可する必要があります。これは、Options ExecCGI パラメータを通じて設定する必要があります。

#AddType text/html .shtml

#AddHandler サーバー解析 .shtml

動的処理のもう 1 つのタイプは、サーバー解析です。自体が Web ページ内のタグを事前に分析し、タグを正しい HTML 識別子に変更します。サーバー解析では text/html タイプのドキュメントを処理する必要があるため、まず対応する .shtml を text/html タイプとして定義します。

ただし、SSI をサポートするには、まず構成ファイル (または .htaccess) で Options include を使用して、このディレクトリ内のドキュメントを SSI タイプにできるようにするか、Options includeNOExec を使用して通常の SSI を実行する必要があります。フラグが設定されていますが、その中で参照されている外部プログラムは実行されません。

サーバーで解析されるタイプを指定するもう 1 つの方法は、XBitBack 設定オプションを使用することです。XBitHack が On に設定されている場合、サーバーはすべての text/html タイプのドキュメント (.html を持つドキュメントを含む) をチェックします。 suffix) の場合、ファイル属性に実行ビット「x」があることが判明した場合、サーバーはそれをサーバー分析ドキュメントとみなし、サーバーで処理する必要があります。 XBitBack を使用するとすべての HTML ドキュメントに対して追加のチェックが実行され、効率が低下するため、設定には AddHandler を使用し、XBitBack を Off に設定することをお勧めします。

#AddHandler send-as-is asis

#AddHandler imap ファイル マップ

#AddHandler type-map var

上記でコメントされた AddHandler は、Apache サーバーの asis、map、var 処理機能をサポートするために使用されます。

# Action media/type /cgi-script/location

# Action handler- name / cgi-script/location

Apache が内部的に提供する処理機能には制限があるため、Action を使用してサーバーの外部プログラムを処理可能な動的ドキュメント タイプとして定義できます。標準の CGI プログラムと同じです。入力データを処理した後、さまざまな MIME タイプの結果が出力されます。たとえば、最初に wri2txt を実行して特殊なサフィックス wri を処理し、その後結果を返す操作を定義するには、次のように使用できます。

Action windows-writer /bin/wri2txt

AddHandler windows- Writer wri

さらに、アクション定義を直接使用して、特定の MIME タイプを前処理することができます。これには、例の最初の形式の Action パラメータ設定メソッドが必要です。この設定方法では、処理操作をファイル拡張子に関連付ける追加の AddHandler は必要なくなりましたが、Action を使用して MIME タイプのファイルを直接処理します。ただし、ドキュメントのサフィックスに正式な MIME タイプがない場合は、最初に MIME タイプを定義する必要があります。

#MetaDir .web

#MetaSuffix .meta

メタ情報は、ドキュメントが送信される前にクライアントのブラウザにデータを事前に送信します。をクライアントに送信するため、ブラウザは実際に GET を通じてすべてのドキュメント データを返さなくても、HEAD リクエストを通じてこのメタ情報にアクセスできます。通常、サーバーはいくつかの標準的な HTTP ヘッダー情報をブラウザーに送信します。追加情報を追加したい場合は、MetaDir を使用してメタ データが保存されるディレクトリを定義する必要があります。また、MetaS サフィックスは、そのサフィックスを指定するために使用されます。メタデータを含むファイル。

#ErrorDocument 500 "サーバーがブーブーしました。

#ErrorDocument 404 /missing.html

#ErrorDocument 404 /cgi-bin/missing_handler.pl

#ErrorDocument 402

http://some.other_server.com/subscription_info.html

顧客が要求した Web ページが存在しない場合、またはこれが発生すると、サーバーはエラー コードを生成し、エラーを識別する Web ページでクライアントのブラウザに応答します。クライアントのブラウザが応答するコンテンツを設定するために ErrorDocument が使用されます。エラーが発生した場合、ErrorDocument の最初のパラメータはシーケンス番号、2 番目のパラメータは単純なテキスト、ローカル Web ページ、ローカル CGI プログラム、リモート ホスト上の Web ページです

BrowserMatch "Mozilla/2" nokeepalive

BrowserMatch "MSIE 4.0b2;" nokeepalive downgrade-1.0 Force-response-1.0

BrowserMatch "RealPlayer 4.0" Force-response- 1.0

BrowserMatch "Java/1.0" Force-response-1.0

BrowserMatch "JDK/1.0" Force-response-1.0

BrowserMatch コマンドは特別なパラメータを設定します特定のクライアント プログラム用に、古いバージョンのブラウザの互換性を確保し、新しいブラウザ機能をサポートします。 🎜># すべての