From da301e1f397a30614b9a39d4d570d6c0236b924f Mon Sep 17 00:00:00 2001 From: Yoshiki Hayashi Date: Sat, 29 Nov 2003 18:43:22 +0000 Subject: [PATCH] New Japanese translation. (Originally ported form 2.0 version, then updated to the newest version.) Submitted by: Yoshiki Hayashi, Hiroaki KAWAI git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@101930 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/core.xml.ja | 3048 +++++++++++++++++++++++++++++++++ docs/manual/mod/core.xml.meta | 1 + 2 files changed, 3049 insertions(+) create mode 100644 docs/manual/mod/core.xml.ja diff --git a/docs/manual/mod/core.xml.ja b/docs/manual/mod/core.xml.ja new file mode 100644 index 0000000000..62746425bd --- /dev/null +++ b/docs/manual/mod/core.xml.ja @@ -0,0 +1,3048 @@ + + + + + + +core +常に使用可能な Apache HTTP サーバのコア機能 +Core + + +AcceptPathInfo +後に続くパス名情報を受け付けるリソースの指定 +AcceptPathInfo On|Off|Default +AcceptPathInfo Default +server config +virtual hostdirectory +.htaccess +FileInfo +Apache 2.0.30 以降で使用可能 + + + +

このディレクティブは実際のファイル名 (もしくは存在するディレクトリの + 存在しないファイル) の後に続くパス名情報があるリクエストを受け付けるか + 拒否するかを制御します。続きのパス名情報はスクリプトには PATH_INFO + 環境変数として利用可能になります。

+ +

例えば、/test/ が、here.html というファイル + 一つのみがあるディレクトリを指しているとします。そうすると、 + /test/here.html/more と /test/nothere.html/more + へのリクエストは両方とも /more を PATH_INFO とします。

+ +

AcceptPathInfo ディレクティブに指定可能な + 三つの引数は:

+ +
+
Off
リクエストは存在するパスにそのまま + マップされる場合にのみ受け付けられます。ですから、上の例の + /test/here.html/more のように、本当のファイル名の + 後にパス名情報が続くリクエストには 404 NOT FOUND エラーが返ります。
+ +
On
前の方のパスが存在するファイルにマップする場合は + リクエストが受け付けられます。上の例の /test/here.html/more + は /test/here.html が有効なファイルにマップすれば + 受け付けられます。
+ +
Default
続きのパス名情報の扱いはリクエストの + ハンドラで決まります。 + 普通のファイルのためのコアハンドラのデフォルトは PATH_INFO を拒否します。 + cgi-script や isapi-isa のようにスクリプトを扱うハンドラは + 一般的にデフォルトで PATH_INFO を受け付けます。
+
+ +

AcceptPathInfo の主な目的はハンドラの PATH_INFO を + 受け付けるか拒否するかの選択を上書きできるようにすることです。 + 例えば、これは例えば INCLUDES のような + フィルタを使って PATH_INFO に + 基づいてコンテンツを生成しているときに必要になります。

+ + + <Files "mypaths.shtml">
+ + Options +Includes
+ SetOutputFilter INCLUDES
+ AcceptPathInfo On
+ + </Files> + + + + + +AccessFileName +分散設定ファイルの名前 +AccessFileName filename [filename] ... +AccessFileName .htaccess +server configvirtual host + + + +

リクエストを処理するとき、サーバはディレクトリに + 対して分散設定ファイルが有効になっていれば、 + そのドキュメントへの + パス上にある全てのディレクトリから、ここで指定された名前の一覧の中で + 最初に見つかったファイルをそれぞれ設定ファイルとして読み込みます。例えば:

+ + + AccessFileName .acl + + +

という設定があると、以下のようにして無効にされていない限り、 + ドキュメント /usr/local/web/index.html + を返す前に、サーバは /.acl, /usr/.acl, + /usr/local/.acl, /usr/local/web/.acl から + ディレクティブを読み込みます。

+ + + <Directory />
+ + AllowOverride None
+ + </Directory> + + +AllowOverride +設定ファイル +.htaccess ファイル + + + +AddDefaultCharset +明示的に文字セットを指定していない応答に追加される +デフォルトの文字セット +AddDefaultCharset On|Off|charset +AddDefaultCharset Off +server config +virtual hostdirectory +.htaccess +FileInfo + + +

このディレクティブは、HTTP ヘッダにコンテントタイプパラメータを + 持たない応答に追加される文字セットの名前を指定します。 + これは、ドキュメント内の META タグで指定されたどのような文字セット + も無効にします。 + AddDefaultCharset Off という設定により、この機能は無効になります。 + AddDefaultCharset On にすれば、ディレクティブの要求通り + Apache 内部のデフォルト文字セット iso-8859-1 に設定します。 + また、他の charset も指定できます。例えば:

+ + + AddDefaultCharset utf-8 + + + + + +AddOutputFilterByType +MIME-type に出力フィルタを割り当てる +AddOutputFilterByType filter[;filter...] MIME-type +[MIME-type] ... +server config +virtual hostdirectory +.htaccess +FileInfo +Apache 2.0.33 以降で使用可能 + + +

このディレクティブは応答の MIME-type に応じて出力フィルタを使用するようにします。

+ +

次の例は mod_deflate の DEFLATE フィルタを + 使っています。text/html と text/plain の + すべての出力 (静的なものも動的なものも) をクライアントに送られる前に + 圧縮します。

+ + + AddOutputFilterByType DEFLATE text/html text/plain + + +

複数のフィルタでコンテンツを処理させたいときは、それぞれの名前をセミコロンで + 分ける必要があります。各フィルタに対して + AddOutputFilterByType を一つずつ書くこともできます。

+ +

次の例は text/html のスクリプトのすべての出力を + まず INCLUDES フィルタで処理し、さらに DEFLATE フィルタにかけます。

+ + + <Location /cgi-bin/>
+ + Options Includes
+ AddOutputFilterByType INCLUDES;DEFLATE text/html
+ + </Location> + + + 注: +

AddOutputFilterByType ディレクティブにより + 有効にしたフィルタは場合によっては、部分的もしくは完全に適用されないことが + あります。例えば、MIME タイプがが決定できないときには + DefaultType の設定が同じだったとしても、 + DefaultType 設定を使うようになります。

+

しかし、確実にフィルタが適用されるようにしたいときは、リソースに + 明示的にコンテントタイプを割り当てることができます。これには例えば + AddType ディレクティブや + ForceType ディレクティブを使います。 + (nphでない) CGI スクリプトでコンテントタイプを設定するというものでも + 大丈夫です。

+ +

タイプ毎の出力フィルタはプロキシリクエストには決して適用されません。

+ + + +AddOutputFilter +SetOutputFilter +フィルタ + + + +AllowEncodedSlashes +URL 中の符号化されたパス分離文字が先に伝えられるのを許可するかどうかを +決定する +AllowEncodedSlashes On|Off +AllowEncodedSlashes Off +server configvirtual host + +Apache 2.0.46 以降で使用可能 + + +

AllowEncodedSlashes ディレクティブは符号化された + パス分離文字 (/ は %2F、さらにシステムによっては + \ に対応する %5C) が存在する URL の使用を + 許可するかどうかを決定します。通常はそのような URL は 404 (Not found) エラー + で拒否されます。

+ +

AllowEncodedSlashes On による + パス分離文字の使用は、PATH_INFO と合わせて + 使うときに一番役に立ちます。

+

Turning AllowEncodedSlashes On is + mostly useful when used in conjunction with PATH_INFO.

+ + 注 +

符号化されたスラッシュを許可することは、復号をすることを + 意味しません。%2F や (関係するシステムでの) + %5C は、他の部分が復号された URL の中でもそのままの形式で + 残されます。

+ + +AcceptPathInfo + + + + +AllowOverride +.htaccess で許可されるディレクティブの種類 +AllowOverride All|None|directive-type +[directive-type] ... +AllowOverride All +directory + + +

サーバが (AccessFileName によって指定された) + .htaccess ファイルを見つけた時、そのファイルの中で + 宣言されたどのディレクティブがより前に定義された設定ディレクティブを + 上書きできるかを知る必要があります。

+ + Only available in <Directory> sections + AllowOverride is valid only in + Directory + sections, not in Location or Files sections. + + +

このディレクティブを None に設定すると、.htaccess ファイルは完全に + 無視されます。 + この場合、サーバはファイルシステムの .htaccess ファイルを読むことを + 試みさえしません。

+ +

このディレクティブが All に設定されている時には、 + .htaccess という コンテキスト を持つ + 全てのディレクティブが利用できます。

+ +

directive-type には、以下のディレクティブ群の + キーワードのどれかを指定します。

+ +
+
AuthConfig
+ +
+ + 認証に関するディレクティブの使用を許可する (AuthDBMGroupFile, + AuthDBMUserFile, + AuthGroupFile, + AuthName, + AuthType, AuthUserFile, Require など。)。
+ +
FileInfo
+ +
+ ドキュメントタイプを制御するためのディレクティブの使用を許可する (DefaultType, ErrorDocument, ForceType, LanguagePriority, + SetHandler, SetInputFilter, SetOutputFilter, + mod_mime の Add* と Remove* + ディレクティブなど。)。
+ +
Indexes
+ +
+ ディレクトリインデックスを制御するためのディレクティブの使用を許可する + (AddDescription, + AddIcon, AddIconByEncoding, + AddIconByType, + DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName + など。)。
+ +
Limit
+ +
+ ホストへのアクセス制御を行うためのディレクティブの使用を許可する (Allow, Deny, Order).
+ +
Options
+ +
+ 特定のディレクトリにおける機能を指定するためのディレクティブの使用を許可する + (Options と + XBitHack).
+
+ +

例:

+ + + AllowOverride AuthConfig Indexes + + + +AccessFileName +設定ファイル +.htaccess ファイル + + + +AuthName +HTTP 認証の認可領域 (訳注: realm) +AuthName auth-domain +directory.htaccess + +AuthConfig + + +

このディレクティブはディレクトリに対する認可領域 (訳注: realm) + の名前を指定します。 + 認可領域は、利用者がどのユーザ名とパスワードを送信すればよいのかを + クライアントに教えるために利用します。 + AuthName は一つの引数をとり、 + スペースが含まれる場合には、 + 引用符で括らなければなりません。 + このディレクティブは + AuthType ディレクティブや + Require ディレクティブと、 + AuthUserFile や + AuthGroupFile などのディレクティブと + 一緒に利用する必要があります。

+ +

例えば:

+ + + AuthName "Top Secret" + + +

ここで AuthName に指定した文字列が、 + 大部分のブラウザのパスワードダイアログに表示されます。

+ +認証、承認、アクセス制御 + + + +AuthType +ユーザ認証の種類 +AuthType Basic|Digest +directory.htaccess + +AuthConfig + + +

このディレクティブは対象ディレクトリで利用するユーザー認証の種類を選びます。 + ただ、現在のところは Basic と Digest しか + 実装されていません。 + + このディレクティブは AuthNameディレクティブや + Require ディレクティブと、 + AuthUserFile や AuthGroupFile などのディレクティブと + 一緒に利用する必要があります。

+ +認証、承認、アクセス制御 + + + +CGIMapExtension +CGI スクリプトのインタープリタの位置を調べるための手法 +CGIMapExtension cgi-path .extension +None +directory.htaccess + +FileInfo +NetWare のみ + + +

このディレクティブは Apache が CGI スクリプトを実行するための + インタープリタを探す方法を制御します。 + 例えば、CGIMapExtension sys:\foo.nlm .foo と設定すると + .foo という拡張子のすべての CGI スクリプトは FOO インタープリタに + 渡されます。

+ + + + +ContentDigest +Content-MD5 HTTP 応答ヘッダの生成を有効にする +ContentDigest On|Off +ContentDigest Off +server configvirtual host +directory.htaccess + +Options +Experimental + + +

このディレクティブは、RFC1864 及び RFC2068 において定義されている + Content-MD5 ヘッダーの生成を有効にします。

+ +

MD5 は、任意長のデータの「メッセージダイジェスト」(「指紋」 + と表現されることもある) を計算するアルゴリズムで、 + データの変更があった場合には非常に高い信頼度でメッセージダイジェストに変更が + 反映されます。

+ +

Content-MD5 ヘッダは、エンドツーエンドで + エンティティボディーに含まれるメッセージの完全性チェック + (Message Integrity Check - MIC)を提供します。 + このヘッダを調べることで、プロキシやクライアントは、 + 途中経路におけるエンティティボディの予期せぬ変更などを + 検出することができます。ヘッダの例:

+ + + Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA== + + +

リクエスト毎にメッセージダイジェストを計算する (値はキャッシュされません) + ことから、 + サーバパフォーマンスが低下することについて注意してください。

+ +

Content-MD5は、core 機能により処理された + ドキュメントを送るときのみ有効であり、 + SSI ドキュメントや CGI スクリプトの出力、バイトレンジを指定した + 応答の場合にはこのヘッダは付与されません。 +

+ + + + +DefaultType +サーバがコンテントタイプを決定できないときに +送られる MIME コンテントタイプ +DefaultType MIME-type +DefaultType text/plain +server configvirtual host +directory.htaccess + +FileInfo + + +

サーバは、MIME のタイプマップからは決定できない + ドキュメントの送信を要求されることがあります。

+ +

サーバは、ドキュメントのコンテントタイプをクライアントに通知する必要が + ありますので、このようにタイプが未知の場合は + DefaultType で指定されたタイプを利用します。 + 例:

+ + + DefaultType image/gif + + +

これは .gif という拡張子がファイル名に含まれていない + 多くの GIF 画像が含まれているディレクトリに適しているでしょう。

+ +

ForceType ディレクティブと + 違って、このディレクティブはデフォルトの MIME タイプを提供するだけで + あることに注意してください。ファイル名の拡張子を含め、 + メディアタイプを決定できる他の MIME タイプの定義があれば + このデフォルトは上書きされます。

+ + + + +Directory +指定のファイルシステムのディレクトリとサブディレクトリとのみに +適用されるディレクティブを囲む +<Directory directory-path> +... </Directory> +server configvirtual host + + + +

指定されたディレクトリとそのサブディレクトリにのみ + ディレクティブを適用させるためには、 + Directory と + </Directory> を対として、ディレクティブ群を囲います。 + その中には、ディレクトリコンテキストで許可された全てのディレクティブを + 利用できます。 + directive-path は、フルパスもしくは Unix のシェル形式の + ワイルドカードを指定します。 + ? は任意の 1 文字、* は任意の文字列にマッチします。 + シェルにおける指定同様、文字の範囲を [] で指定できます。 + ワイルドカードは `/' 文字にはマッチしませんので、 + /home/user/public_html には + <Directory /*/public_html> はマッチしませんが、 + <Directory /home/*/public_html> はマッチします。 + 例:

+ + + <Directory /usr/local/httpd/htdocs>
+ + Options Indexes FollowSymLinks
+ + </Directory> + + + +

directory-path 引数には注意してください: その引数は +Apache がファイルをアクセスするために使うファイルシステムのパスに +そのままマッチする必要があります。ある <Directory> に +適用されるディレクティブは、別のシンボリックリンクをたどったりして +同じディレクトリを違うパスでアクセスした場合には適用されません。

+ + +

~ という文字を + 付加することで拡張正規表現を利用することもできます。 + 例えば:

+ + + <Directory ~ "^/www/.*/[0-9]{3}"> + + +

といった指定の場合、/www/ 以下にある数字 + 3 文字のディレクトリにマッチします。

+ +

もし複数の (正規表現以外の) Directoryセクションが + ドキュメントを含むディレクトリ (やその上位ディレクトリのどれか) とマッチしたならば、 + .htaccess ファイルのディレクティブも読み込みつつ、 + 短いパスから順に適用されます。 + 例えば、

+ + + <Directory />
+ + AllowOverride None
+ + </Directory>
+
+ <Directory /home/>
+ + AllowOverride FileInfo
+ + </Directory> + + +

と設定し、ドキュメント /home/web/dir/doc.html への + アクセスがあった場合には以下のように動作します:

+ +
    +
  • AllowOverride None が適用される。 + (.htaccess ファイルは無効になる)
    • + +
  • AllowOverride FileInfo が適用される + (/home ディレクトリに対して)。
    • + +
  • /home/.htaccess, /home/web/.htaccess, + /home/web/.htaccess の順にそれらのファイル中の + FileInfo ディレクティブが適用される。
    • +
+ +

正規表現は、通常のセクションがすべて適用されるまで + 考慮されません。 + その後、全ての正規表現が設定ファイルに現れた順で試されます。 + 例えば、以下のような場合に

+ + + <Directory ~ abc$>
+ + # ... directives here ...
+ + </Directory> + + +

正規表現のセクションはすべての通常の Directory と + .htaccess の適用が終わるまで考慮されません。 + その後で、正規表現は /home/abc/public_html/abc にマッチし、 + 対応する Directory が適用されます。

+ +

Apache のデフォルトでは <Directory /> へのアクセスは + Allow from All になっていることに注意してください。 + これは、URL からマップされたどのファイルでも Apache は送るということです。 + これは以下のようにして変更することが推奨されています。

+ + + <Directory />
+ + Order Deny,Allow
+ Deny from All
+ + </Directory> + + +

そしてアクセスを可能にしたいディレクトリに対して + 個別に設定すればよいでしょう。 + このあたりについては、セキュリティに関するコツを + 参照してください。

+ +

ディレクトリセクションは httpd.conf ファイル書きます。 + Directory + ディレクティブは入れ子にすることができず、 + Limit や LimitExcept セクションの中にも + 記述できません。

+ + +リクエストを受けた際にこれらの異なるセクションが + 組み合わされる方法については + <Directory>, <Location>, <Files> セクションの動作法 + + + +DirectoryMatch +正規表現にマッチするファイルシステムのディレクトリと +サブディレクトリとのみに適用されるディレクティブを囲む +<DirectoryMatch regex> +... </DirectoryMatch> +server configvirtual host + + + +

Directory + ディレクティブと同様に、DirectoryMatch + と </DirectoryMatch> は指定されたディレクトリと + そのサブディレクトリにのみ適用されるディレクティブ群を囲います。 + しかし、このディレクティブは引数として正規表現をとります。例えば:

+ + + <DirectoryMatch "^/www/.*/[0-9]{3}"> + + +

は /www/ 以下にある数字 3 文字のディレクトリにマッチします。

+ + +通常の Directory と正規表現の指定が +適用される順番については Directory +リクエストを受けた際にこれらの異なるセクションが + 組み合わされる方法については + <Directory>, <Location>, <Files> セクションの動作法 + + + +DocumentRoot +ウェブから見えるメインのドキュメントツリーになる +ディレクトリ +DocumentRoot directory-path +DocumentRoot /usr/local/apache/htdocs +server configvirtual host + + + +

このディレクティブは、httpd がファイルを提供するディレクトリを設定します。 + Alias のようなディレクティブにマッチしない場合には、 + ドキュメントの (訳注:ファイルシステム上の) パスを生成するために、 + リクエストされた URL のパス部分をドキュメントルートに付与します。 + 例:

+ + + DocumentRoot /usr/web + + +

この場合、 + http://www.my.host.com/index.html へのアクセスがあれば + /usr/web/index.html が返されます。 + directory-path が絶対パスでない場合は、 + ServerRoot + からの相対パスとみなされます。

+ +

DocumentRoot は最後のスラッシュ無しで + 指定する必要があります。

+ +URL をファイルシステムの位置に +マップする + + + +EnableMMAP +配送中にファイルを読み込むためにメモリマッピングを +使うかどうか +EnableMMAP On|Off +EnableMMAP On +server configvirtual host +directory.htaccess + +FileInfo + + +

このディレクティブは配送中にファイルの内容を読み込む必要があるときに + httpd がメモリマッピングを使うかどうかを制御します。デフォルトでは、 + 例えば、mod_include を使って SSI ファイルを配送 + するときのように、ファイルの途中のデータをアクセスする必要があるときには + Apache は OS がサポートしていればファイルをメモリにマップします。

+ +

+ このメモリマップは性能の向上を持たらすことがあります。 + しかし、環境によっては運用上の問題を防ぐためにメモリマッピングを + 使用しないようにした方が良い場合もあります:

+ +
    +
  • マルチプロセッサシステムの中にはメモリマッピングをすると httpd の + 性能が落ちるものがあります。
    • +
  • NFS マウントされた DocumentRoot + では、httpd がメモリマップしている間にファイルが削除されたり + 短くなったりしたときに起こるセグメンテーションフォールトのために + httpd がクラッシュする可能性があります。
    • +
+ +

これらの問題に当てはまるサーバの設定の場合は、以下のようにして + ファイルの配送時のメモリマッピングを使用不可にしてください:

+ + + EnableMMAP Off + + +

NFS マウントされたファイルには、問題のあるファイルにのみ明示的に + この機能を使用不可にします:

+ + + <Directory "/path-to-nfs-files"> + + EnableMMAP Off + + </Directory> + + + + + +EnableSendfile +ファイルのクライアントへの配送時にカーネルの sendfile サポートを +使うかどうか +EnableSendfile On|Off +EnableSendfile On +server configvirtual host +directory.htaccess + +FileInfo +バージョン 2.0.44 以降で使用可能 + + +

このディレクティブはクライアンにファイルの内容を送るときに + httpd がカーネルの + sendfile サポートを使うかどうかを制御します。デフォルトでは、 + 例えば静的なファイルの配送のように、リクエストの処理にファイルの + 途中のデータのアクセスを必要としないときには、Apache は OS が + サポートしていればファイルを読み込むことなく sendfile を使って + ファイルの内容を送ります。

+ +

sendfile は read と send を別々に行なうことと、バッファの割り当てを + 回避します。しかし、プラットフォームやファイルシステムの中には + 運用上の問題を避けるためにこの機能を使用不可にした方が良い場合があります:

+ +
    +
  • プラットフォームの中にはビルドシステムが検知できなかった、壊れた + sendfile のサポートが存在するものがあります。これは特に + バイナリが別のマシンでビルドされ、壊れた sendfile のあるマシンに + 移動したときに起こります。
    • +
  • Linux では、sendfile を用いると、 + IPv6 使用時に存在する特定ネットワークカードの TCP-checksum + オフロードのバグを踏んでしまいます。
    • +
  • ネットワークマウントされた DocumentRoot + (例えば NFS や SMB) + では、カーネルは自身のキャッシュを使ってネットワークからのファイルを + 送ることができないことがあります。
    • +
+ +

これらの問題に当てはまるサーバの設定の場合は、以下のようにして + この機能を使用不可にしてください:

+ + + + EnableSendfile Off + + +

NFS や SMB マウントされたファイルには、問題のあるファイルにのみ明示的に + この機能を使用不可にします:

+ + + <Directory "/path-to-nfs-files"> + + EnableSendfile Off + + </Directory> + + + + + +ErrorDocument +エラーが発生したときにサーバがクライアントに送るもの +ErrorDocument error-code document +server configvirtual host +directory.htaccess + +FileInfo +Apache 2.0 ではテキストをクウォートする構文が以前のバージョンから +変わっています。 + + +

問題やエラーが発生したときの動作として、 + Apache には以下の四つのうち一つの動作を設定することができます。

+ +
    +
  1. Apache 標準の簡単なエラーメッセージを表示
    2. + +
  2. 自分で指定したメッセージを表示
    3. + +
  3. 問題やエラーの処理をする為に、自サーバ内の + URL-path へリダイレクト
    4. + +
  4. 問題やエラーの処理をする為に、外部の URL へリダイレクト
    5. +
+ +

最初のものがデフォルトの動作で、2 番目から 4 番目は、 + ErrorDocumentディレクティブにより、 + HTTP のレスポンスコードと、メッセージか URL を指定することで設定します。 + Apache が問題もしくはエラーに関する追加情報を提供することがあります。

+ +

URL の場合は、ローカルの URL の指定としてスラッシュで始まる (/) パスか、 + クライアントが解釈できるフル URL を指定します。
+ もしくは、ブラウザに表示されるメッセージを指定できます。 + 例:

+ + + ErrorDocument 500 http://foo.example.com/cgi-bin/tester
+ ErrorDocument 404 /cgi-bin/bad_urls.pl
+ ErrorDocument 401 /subscription_info.html
+ ErrorDocument 403 "Sorry can't allow you access today" + + +

リモート URL (例えば、頭に http と付与した方法) を + ErrorDocument に指定するとき、 + たとえ文書が同じサーバにあろうとも、ドキュメントがどこにあるかを通知するために、 + Apache はリダイレクトをクライアントに送出するということに、注意してください。 + これにはいろいろと関連して起こる問題があります。 + 中でも最も重要なのは、クライアントは元々のエラーステータスコードを受け取らず、 + 代わりにリダイレクトのステータスコードを受け取るということです。 + これにより、ステータスコードを使って URL が有効であるかどうかを決定しようとする + ウェブロボットやその他クライアントを、混乱させるかもしれません。 + さらに、ErrorDocument 401 にリモートの URL を指定すると、 + クライアントは 401 というステータスコードを受け取らないため、 + パスワードをユーザーに入力要求しなければならないことがわかりません。 + 従って、ErrorDocument 401 というディレクティブを使う場合は、 + 必ずローカルな文書を参照しなければなりません。

+ +

Microsoft Internet Explorer (MSIE) はデフォルトではサーバが生成したエラーメッセージが + 「小さすぎる」ときには無視をして自分自身の「やさしい」エラーメッセージで + 置換します。サイズのしきい値はエラーの種類によって異なりますが、 + 一般的にはエラーの文書を 512 バイトよりも多きくすると、MSIE は + サーバが生成したエラーを隠さずに表示します。詳しい情報は Microsoft + Knowledgebase の記事 Q294807 + にあります。

+ +

2.0 より前のバージョンでは、対になっていない二重引用符を + 先頭に付けることによりメッセージであることを指定していました。

+ + + +カスタマイズ可能な +エラー応答のドキュメンテーション + + + +ErrorLog +サーバがエラーをログ収集する場所 + ErrorLog file-path|syslog[:facility] +ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2) +server configvirtual host + + + +

ErrorLog ディレクティブは、 + サーバに生じたさまざまなエラーを + 記録する為のファイルの名前を設定します。 + file-path が絶対パスでないときは、ServerRoot からの相対パスとみなされます。

+ + 例 + ErrorLog /var/log/httpd/error_log + + +

file-path がパイプ (|) から始まる場合は、 + エラーログを処理するために実行されるコマンドが + 指定されていると解釈されます。

+ + 例 + ErrorLog "|/usr/local/bin/httpd_errors" + + +

ファイル名の変わりに syslog と指定することによって、 + システムがサポートしていれば syslogd(8) を利用したロギングが有効になります。 + デフォルトでは、local7 ファシリティとなりますが、 + syslog:facility といった形で記述することにより、 + 通常 syslog(1) のドキュメントで説明されているファシリティの一つを使うように + することができます。

+ + 例 + ErrorLog syslog:user + + +

セキュリティ: + ログファイルを格納するディレクトリが、サーバを起動したユーザ以外の + ユーザによって書き込める場合にセキュリティが破られる可能性があることに + 関する詳細は セキュリティに関するコツ を + 参照してください。

+ 注 +

Unix 以外のプラットフォームでファイルのパスを入力するときは、 + プラットフォームがバックスラッシュの使用を許していたとしても、 + 確実にスラッシュのみが使用されるように注意してください。一般的には、 + 設定ファイル全般でスラッシュのみを使う方が良いでしょう。

+ + +LogLevel +Apache ログファイル + + + +FileETag +ETag HTTP 応答ヘッダを作成するために使用される +ファイルの属性 +FileETag component ... +FileETag INode MTime Size +server configvirtual host +directory.htaccess + +FileInfo + + +

+ FileETag ディレクティブは + ドキュメントがファイルに基づいたものであるときに、 + ETag (エンティティタグ) 応答ヘッダフィールドを作成するときに使用する + ファイルの属性を設定します。 (ETag の値はネットワークの帯域を節約するための + キャッシュの管理で使われます。) Apache 1.3.22 以前では、ETag の値は + 常にファイルの inode, サイズ、最終修正時刻 (mtime) から作成 + されていました。FileETag ディレクティブにより、これらのどれを使うかを + 選ぶことができます。認識されるキーワードは: +

+ +
+
INode
+
ファイルの inode 番号を計算に使います
+
MTime
+
ファイルの最終修正時刻を使います
+
Size
+
ファイルの中身のバイト数を使います
+
All
+
使用可能なすべてのフィールドを使います。 + これは FileETag INode MTime Size と等価です。
+
None
+
ドキュメントがファイルに基づいたものでも、ETag フィールドを + 応答に付加しません
+
+ +

INode, MTime, Size キーワードには + + や - を前に付けて + 指定することもできます。この場合は、より広い範囲から継承された + デフォルトの設定に変更を加えるようになります。そのような接頭辞の + 無いキーワードを指定すると、即座に継承した設定を無効にします。

+ +

あるディレクトリの設定に + FileETag INode MTime Size があり、 + サブディレクトリの設定に FileETag -INode があるときは、 + そのサブディレクトリの設定は (設定が上書きされなければサブディレクトリの + サブディレクトリにも継承されます) FileETag MTime Size + と同じになります。

+ + + + +Files +マッチするファイル名に適用されるディレクティブを囲む +<Files filename> ... </Files> +server configvirtual host +directory.htaccess + +All + + +

Files ディレクティブは、 + その中にあるディレクティブの適用範囲をファイル名で制限します。 + Directory ディレクティブや Location ディレクティブと + 同じような機能を持ちます。 + これは、</Files> ディレクティブと対に + なっていなければなりません。 + このセクション中のディレクティブは、ベース名 (ファイル名の最後の部分) + が指定されたファイル名にマッチするすべてのオブジェクトに適用されます。 + Files セクションは + Directory セクションと + .htaccess が読み込まれた後、 + Location セクションよりは先に + 設定ファイルに現れた順に適用されます。 + Files は、 + Directory セクション内に + ネストさせることができ、 + ファイルシステムの一部にのみ限定して適用させることができます。

+ +

filename 引数は、ファイル名かワイルドカード文字列 + で、ワイルドカードでは ? は一つの文字、* は任意の文字列にマッチします。 + ~ という文字を付加することで拡張正規表現を使うこともできます。 + 例えば、

+ + + <Files ~ "\.(gif|jpe?g|png)$"> + + +

とすることにより、一般的なインターネットの画像フォーマットにマッチします。 + ただし、 + FilesMatch を使う方が + 推奨されています。

+ +

ちなみに、Directory と Location セクションとは異なり、 + Files + は .htaccess ファイル内で利用することができます。 + これにより、ユーザがファイル毎にアクセスの制御を行なうことができるように + なっています。

+ + +リクエストを受けた際にこれらの異なるセクションが + 組み合わされる方法については + <Directory>, <Location>, <Files> セクションの動作法 + + + +FilesMatch +正規表現にマッチするファイル名に適用される +ディレクティブを囲む +<FilesMatch regex> ... </FilesMatch> +server configvirtual host +directory.htaccess + +All + + +

FilesMatch ディレクティブは、 + Files + ディレクティブ同様にその中にあるディレクティブの適用範囲をファイル名で制限します。ただし、 + このディレクティブには正規表現を指定します。 + 例えば:

+ + + <FilesMatch "\.(gif|jpe?g|png)$"> + + +

は一般的なインターネットの画像形式にマッチします。

+ + +リクエストを受けた際にこれらの異なるセクションが + 組み合わされる方法については + <Directory>, <Location>, <Files> セクションの動作法 + + + +ForceType +すべてのマッチするファイルが指定の MIME コンテントタイプで +送られるようにする +ForceType MIME-type|None +directory.htaccess + +FileInfo +Apache 2.0 で core に移動 + + +

.htaccess や Directory セクション、 + Location セクション、 + Files セクションに + 書かれた場合、このディレクティブはそこにあるすべてのファイルが + MIME-type + で指定されたコンテントタイプとして扱われるようにします。たとえば、 + GIF ファイルばかりのディレクトリがあって、すべてのファイルを .gif + で終わらせたくはないときに、以下のものを使用します:

+ + + ForceType image/gif + + +

DefaultType と違って + このディレクティブはメディアタイプを決めることができるかもしれない + ファイルの拡張子も含め、すべての MIME タイプの関連付けを + 上書きすることに注意してください。

+ +

None という値を使うことで ForceType の + 設定を無効にできます:

+ + + # force all files to be image/gif:
+ <Location /images>
+ + ForceType image/gif
+ + </Location>
+
+ # but normal mime-type associations here:
+ <Location /images/mixed>
+ + ForceType None
+ + </Location> + + + + + +HostnameLookups +クライアントの IP アドレスの DNS ルックアップを +有効にする +HostnameLookups On|Off|Double +HostnameLookups Off +server configvirtual host +directory + + +

このディレクティブは、ホスト名をログ収集できるように + DNS ルックアップを有効にします + (さらに、CGI/SSI に REMOTE_HOST 変数として渡します)。 + Doubleを指定した場合、2 重の逆引きを行ないます。 + つまり、逆引きの後に、その結果に対して正引きを行ないます。正引きの + 結果の IP アドレスの中にオリジナルのアドレスと一致するものがなければ + なりません。("tcpwrappers" の用語では PARANOID と呼ばれています。)

+ +

mod_authz_host でホスト名によるアクセス + 制御を行なう場合には、 + 設定の如何によらず 2 重の逆引きが実行されます。 + これは、セキュリティを保つために必要です。 + HostnameLookups Double を設定しない限り、 + 他の部分はこの 2 重逆引きの結果を使うことはできません。 + 例えば、HostnameLookups On と設定してある状態で、 + ホスト名によるアクセス制限を行なったオブジェクトへの + リクエストを受けたとすると、2 重の逆引きが成功するか否かによらず、 + REMOTE_HOST には通常の逆引き結果が渡されます。

+ +

ディレクティブのデフォルトは + 本当に逆引きを必要としているわけではないサイトの + ネットワークトラフィックを低減させるために、Off になっています。 + ルックアップによる余計な遅延がなくなるため、 + エンドユーザにとっても良いでしょう。 + DNS のルックアップには、かなりの時間が必要となる場合が多く、 + 負荷の高いサイトではこのディレクティブは Off にすべきです。 + なお、/support ディレクトリに含まれ、デフォルトでは + インストールディレクトリの bin サブディレクトリに + インストールされる logresolve ユーティリティにより、 + Apache の動作とは別に、ログに残されている IP アドレスからホスト名を + ルックアップすることが可能です。

+ + + + +IfDefine +起動時にテストが真であるときのみに処理されるディレクティブを +囲む +<IfDefine [!]parameter-name> ... + </IfDefine> +server configvirtual host +directory.htaccess + +All + + +

<IfDefine test>...</IfDefine> + セクションは、 + ディレクティブを条件付きで指定するために利用します。 + IfDefine セクションに + 含まれるディレクティブは、testが + 定義されているときのみ処理されます。 + もし test が定義されていなければ、 + 開始と終了の指定の間のディレクティブは無視されます。

+ +

IfDefine セクションディレクティブに + 指定する test は、 + 次の二つの形式のうちの一つをとります:

+ +
    +
  • parameter-name
    • + +
  • !parameter-name
    • +
+ +

前者の場合には、parameter-name と名付けられたパラメータが + 定義されていれば開始と終了の間のディレクティブが処理されます。 + 後者の場合は逆で、parameter-name が指定されていない + 場合に処理されます。

+ +

parameter-name 引数は、サーバを起動する際に + httpd のコマンドラインに + -Dparameter- という形で指定すると定義されます。

+ +

IfDefine セクションは + 入れ子にすることができ、複数のパラメータによるテストをするために使用できます。 + 例:

+ + + httpd -DReverseProxy ...
+
+ # httpd.conf
+ <IfDefine ReverseProxy>
+ + LoadModule rewrite_module modules/mod_rewrite.so
+ LoadModule proxy_module modules/libproxy.so
+ + </IfDefine> + + + + + +IfModule +モジュールの存在するかしないかに応じて処理される +ディレクティブを囲む +<IfModule [!]module-name> ... + </IfModule> +server configvirtual host +directory.htaccess + +All + + +

<IfModule test>...</IfModule> + セクションは、モジュールが存在するときに処理されるディレクティブを + 指定するために利用します。 + IfModule セクションに + 含まれるディレクティブは、test + で指定するモジュールが組み込まれているときのみ処理されます。 + もし test が組み込まれていなければ、開始と終了の間のディレクティブ + は無視されます。

+ +

IfModule セクションディレクティブに + 指定する test は、 + 次の二つの形式のうちの一つをとります。

+ +
    +
  • module name
    • + +
  • !module name
    • +
+ +

前者の場合は、module name と名付けられたモジュールが + Apache に組み込まれていれば + (コンパイル済みのものと、LoadModule を利用して + 動的に読み込んだものの両方)、 + 開始と終了の間のディレクティブが処理されます。 + 後者の場合は逆で、module name が組み込まれていない + 場合に処理されます。

+ +

module name 引数は、 + コンパイルをした時のモジュールのファイル名で、 + 例えば mod_rewrite.c といった形になります。 + モジュールが複数のソースファイルから構成されている場合は、文字列 + STANDARD20_MODULE_STUFF があるファイルの名前を + 使ってください。

+ +

IfModule セクションは + 入れ子にすることが可能であり、 + 複数のモジュールのテストを行なうために使用できます。

+ + 特定のモジュールの存在に関わらず動作する + 設定ファイルの原本が必要なときにのみこのセクションを使用してください。 + 通常の動作では、ディレクティブを + IfModule セクションの中に + 入れる必要はありません。 + + + + +Include +サーバ設定ファイル中から他の設定ファイルを取り込む +Include file-path|directory-path +server configvirtual host +directory + +ワイルドカードによるマッチは 2.0.41 以降で使用可能 + + +

このディレクティブにより、サーバの設定ファイルから + 他の設定ファイルをインクルードすることができます。

+ +

複数のファイルをアルファベット順に一度に読み込むために、 + シェル形式 (fnmatch) のワイルドカード文字を使うことができます。 + さらに、Include にディレクトリを指定した場合は、 + ディレクトリとそのサブディレクトリ内の全てのファイルを + アルファベット順に読み込んで、設定ファイルとして処理します。 + しかし、ディレクトリ全体を読み込むのはお勧めできません。 + ふとしたことから httpd が読み込みに失敗するような + 一時ファイルをディレクトリに残してしまうようなことがよくあるからです。

+ +

指定するファイルパスは絶対パスか、 + ServerRoot ディレクトリからの + 相対パスか、のどちらかです。

+ +

例:

+ + + Include /usr/local/apache2/conf/ssl.conf
+ Include /usr/local/apache2/conf/vhosts/*.conf + + +

ServerRoot からの相対パスの場合は:

+ + + Include conf/ssl.conf
+ Include conf/vhosts/*.conf + + +

apachectl configtest を実行すると、設定をチェックしている時に + 読み込まれたファイルのリストが表示されます:

+ + + root@host# apachectl configtest
+ Processing config file: /usr/local/apache2/conf/ssl.conf
+ Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf
+ Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf
+ Syntax OK + + + +apachectl + + + +KeepAlive +HTTP の持続的な接続を有効にする +KeepAlive On|Off +KeepAlive On +server configvirtual host + + + +

HTTP/1.0 の Keep-Alive 拡張と HTTP/1.1 の持続的接続の機能は、 + 複数のリクエストが同じ TCP の接続で送られる、長時間持続する + HTTP セッションを提供します。たくさんの画像が + 含まれる HTML ドキュメントでは場合によっては遅延時間が 50% 短縮される結果も + でています。Keep-Alive 接続を有効にするには + KeepAlive On と設定します。

+ +

HTTP/1.0 に対応したクライアントの際には、 + クライアントより特に要求があった場合のみ Keep-Alive 接続となります。 + さらに、HTTP/1.0 クライアントでは、コンテンツの容量が先に + (訳注: 要求に対して応答を返す前に) わかる場合のみ Keep-Alive + 接続を利用できます。 + これは、CGI の出力や SSI のページ、 + サーバが生成したディレクトリのリストのような動的コンテンツを + HTTP/1.0 クライアントに送る場合には Keep-Alive 接続を使えないことを意味します。 + HTTP/1.1 に対応したクライアントの際には、 + 特に指定されない限りはデフォルトとして持続的な接続が行なわれます。 + クライアントが要求すれば、コンテンツの容量を判別できないものを + 持続的な接続を通して送るために、チャンクエンコーディングが用いられます。

+ + +MaxKeepAliveRequests + + + +KeepAliveTimeout +持続的な接続で次のリクエストが来るまでサーバが待つ時間 +KeepAliveTimeout seconds +KeepAliveTimeout 15 +server configvirtual host + + + +

接続を閉じる前に、Apache が次のリクエストを何秒待つかを指定します。 + リクエストを受け付けた後は、Timeout ディレクティブによって + 指定されたタイムアウト値が使われます。

+ +

KeepAliveTimeout を大きな値に設定すると、 + 負荷の高いサーバにおいてはパフォーマンスの問題を引き起こす場合があります。 + タイムアウトが長ければ長いほど、より多くのサーバプロセスが + 活発でないクライアントからの接続の終了を待ち続けることになります。

+ + + + +Limit +囲いの中にあるアクセス制御の適用を特定の HTTP メソッドのみに +制限する +<Limit method [method] ... > ... + </Limit> +server configvirtual host +directory.htaccess + +All + + +

アクセス制御は、通常全てのアクセスメソッドに対して + 影響し、普通はこれが望ましい挙動です。 + そうしたことから、大部分の場合にはアクセス制御に関わるディレクティブを + Limit セクション内に + 書くべきではありません。

+ +

Limit ディレクティブの + 目的は、アクセス制御の範囲を + 指定された HTTP メソッドに限定するためです。 + それ以外のメソッドは、Limit で囲われたアクセス制御の + 影響を受けません。 + 以下の例は、POST, PUT, DELETE のメソッドに対してのみアクセスの制御を行ない、 + それ以外のメソッドについては制限しません:

+ + + <Limit POST PUT DELETE>
+ + Require valid-user
+ + </Limit> + + +

メソッド名には以下の中から一つ以上を列挙することができます: + GET, + POST, PUT, DELETE, + CONNECT, OPTIONS, + PATCH, PROPFIND, PROPPATCH, + MKCOL, COPY, MOVE, + LOCK, UNLOCK. メソッド名は + 大文字小文字を区別します。 GET を指定した場合には + HEAD リクエストにも制限がかかります。TRACE + メソッドに制限をかけることはできません。

+ + アクセス制御が目的の場合は + Limit + セクションの代わりに LimitExcept セクションを使用した方が良いでしょう。 + LimitExcept + セクションでは不特定のメソッドに対しても防御できるからです。 + + + + + +LimitExcept +指定されたもの以外の HTTP メソッドにアクセス制御を +制限する +<LimitExcept method [method] ... > ... + </LimitExcept> +server configvirtual host +directory.htaccess + +All + + +

LimitExcept と + </LimitExcept> は、引数に + 含まれていない + HTTP のアクセスメソッドに適用するためのアクセス制御 + ディレクティブを括るために利用します。 + つまり、Limit セクションの反対の動作をし、 + 標準のメソッドと標準外や未認識のメソッドの場合の両方を設定できます。 + Limit のドキュメントも + 併せて参照してください。

+ +

例:

+ + + <LimitExcept POST GET>
+ + Require valid-user
+ + </LimitExcept> + + + + + + +LimitInternalRecursion +内部リダイレクトと入れ子になったサブリクエストの最大数を決定する +LimitInternalRecursion number [number] +LimitInternalRecursion 10 +server configvirtual host + +Apache 2.0.47 以降で使用可能 + + +

内部リダイレクトは例えば Action ディレクティブを + 使っているときに起こります。Action ディレクティブは + 元々のリクエストを CGI スクリプトに内部リダイレクトを行ないます。 + サブリクエストはいくつかの URI に対して、リクエストされたときに + 何が起こるかを調べるための Apache の機構です。例えば、mod_dir + は DirectoryIndex ディレクティブ + がリストするファイルを調べるためにサブリクエストを使います。

+ +

LimitInternalRecursion は内部リダイレクトや + サブリクエストが無限ループに陥ったときのサーバクラッシュを防ぎます。 + 普通、そのようなループは設定に失敗したときに発生します。

+ +

このディレクティブは、リクエスト毎に評価される、二つの違う限界値を + 設定します。最初の number は、起こり得る + 内部リクエストの最大値を設定します。二つめの number は + サブリクエストが入れ子にできる深さを設定します。number を + 一つだけ指定したときは、両方の限界値にその値が設定されます。

+ + 例 + LimitInternalRecursion 5 + + + + + +LimitRequestBody +クライアントから送られる HTTP リクエストのボディの +総量を制限する +LimitRequestBody bytes +LimitRequestBody 0 +server configvirtual host +directory.htaccess + +All + + +

このディレクティブは、リクエストボディに許されるバイト数、bytes + を 0 (無制限を意味します) から 2147483647 (2GB) までの数値で指定します。

+ +

LimitRequestBody ディレクティブは、 + ディレクティブが書かれたコンテキスト + (サーバ全体、ディレクトリ、ファイル、ロケーション) 内で + 許容する HTTP リクエストメッセージボディのサイズに制限をかけることができます。 + クライアントのリクエストがその制限値を越えていれば、 + サーバはリクエストを処理せずにエラーを返します。 + 普通のリクエストメッセージボディのサイズは、リソースの種類や + 許可されているメソッドによって大きく変わります。 + CGI スクリプトは、よく情報を受信するために + メッセージボディを使います。 + PUT メソッドの実装は、このディレクティブの値として + 少なくともあるリソースに対してサーバが受け付けようとする + 表現の大きさほどの値を必要とします。

+ +

このディレクティブは、 + 管理者にクライアントからの異常なリクエストを制御できるようにし、 + 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。

+ +

ある場所へのファイルアップロードを許可する場合に、 + アップロードできるファイルのサイズを 100K に制限したければ、 + 以下のように指定します:

+ + + LimitRequestBody 102400 + + + + + + +LimitRequestFields +クライアントからの HTTP リクエストのヘッダフィールドの数を +制限する +LimitRequestFields number +LimitRequestFields 100 +server config + + +

number には、0 (無制限を意味します) から 32767 + までの整数を指定します。 + デフォルト値は、定数 DEFAULT_LIMIT_REQUEST_FIELDS + によりコンパイル時に定義されます (配布時には 100 と指定されています)。

+ +

LimitRequestBody ディレクティブは、 + サーバ管理者が HTTP リクエスト中において許可するリクエストヘッダフィールド数を + 指定します。 + サーバはこの値には通常のクライアントからのリクエストに含まれるであろう + フィールドの数より大きな値が必要とします。 + クライアントにより使われた要求ヘッダーフィールドの数が + 20 を超えることはほとんどありませんが、 + これは種々のクライアントの実装よって変わり、 + 詳細なコンテントネゴシエーションをするためのブラウザの設定までにも + 影響されることがあります。 + オプションの HTTP 拡張はリクエストヘッダフィールドを使って現される場合が + 多くあります。

+ +

このディレクティブは、 + 管理者にクライアントからの異常なリクエストを制御できるようにし、 + 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。 + リクエストのフィールドが多過ぎることを意味するエラー応答が + 普通のクライアントに返されるような時はこの値を増やしてください。

+ +

例:

+ + + LimitRequestFields 50 + + + + + + +LimitRequestFieldSize +クライアントからの HTTP リクエストのヘッダの +サイズを制限する +LimitRequestFieldsize bytes +LimitRequestFieldsize 8190 +server config + + +

このディレクティブは、HTTP リクエストヘッダ内に含めることのできる + バイト数、bytes を + 0 からコンパイル時に定義される定数 + DEFAULT_LIMIT_REQUEST_FIELDSIZE (配布時には 8192 と指定) + で指定された値までの数字で指定します。

+ +

LimitRequestFieldSize ディレクティブは、 + サーバのコンパイル時に指定したインプットバッファ容量以下に + HTTP リクエストヘッダの許容されるサイズを制限することができます。 + サーバは、このディレクティブの値として、 + 通常のクライアントリクエストから送られた個々のヘッダフィールドに + 十分足る大きさを必要とします。 + 普通のリクエストヘッダのサイズは、個々のクライアントにより大きく変わり、 + 詳細なコンテントネゴシエーションをするためのブラウザの設定までにも + 影響されることがあります。

+ +

このディレクティブは、 + 管理者にクライアントからの異常なリクエストを制御できるようにし、 + 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。

+ +

例:

+ + + LimitRequestFieldSize 4094 + + + 通常はデフォルトから変更する必要はありません。 + + + + + +LimitRequestLine +クライアントからの HTTP リクエスト行のサイズを制限する +LimitRequestLine bytes +LimitRequestLine 8190 +server config + + +

このディレクティブは、HTTP リクエスト行内で許容されるバイト数 + bytes を 0 からコンパイル時の定数 + DEFAULT_LIMIT_REQUEST_LINE (配布時には 8190 と指定) + で指定された値までの数字で指定します。

+ +

LimitRequestLine ディレクティブにより、サーバ管理者は + サーバのコンパイル時に指定したインプットバッファ容量以下に + クライアントからの HTTP リクエスト行のサイズの制限を行なうことができます。 + リクエスト行は、HTTPメソッド、URI、プロトコルバージョンから成っており、 + LimitRequestLine はサーバへのリクエストに対して + 許容するリクエスト URI の長さを制限することになります。 + サーバは、GET リクエストのクエリ部分も含めて、リソースの名前が入るに足る + 大きさを必要とします。

+ +

このディレクティブは、 + 管理者にクライアントからの異常なリクエストを制御できるようにし、 + 何らかの形のサービス拒否攻撃 (訳注:DoS) を避けるのに有効です。

+ +

例:

+ + + LimitRequestLine 4094 + + + 通常はデフォルトから変更する必要はありません。 + + + + +LimitXMLRequestBody +XML 形式のリクエストのボディのサイズを制限する +LimitXMLRequestBody bytes +LimitXMLRequestBody 1000000 +server configvirtual host +directory.htaccess +All + + +

XML 形式のリクエストのボディの最大値を (バイト単位で) 制限します。 + 値に 0 を指定するとチェックを無効にします。

+ +

例:

+ + + LimitXMLRequestBody 0 + + + + + + +Location +囲んだディレクティブをマッチする URL のみに適用 +<Location + URL-path|URL> ... </Location> +server configvirtual host + + + +

Location ディレクティブは、 + URL により中に書かれたディレクティブの適用範囲を制限します。 + Directory + ディレクティブと似ていて、 + </Location> ディレクティブで終了する + サブセクションを開始します。 + Location セクションは、 + Directory セクションと + .htaccess の読み込みの後、 + Files セクションを + 適用した後に、設定ファイルに現れた順に処理されます。

+ +

Location セクションは + 完全にファイルシステムと関連せずに動作します。このことから導かれる + 結果にはいつくか注意する点があります。最も重要なものは、 + ファイルシステムの位置へのアクセス制御に Location ディレクティブを使うべきではない + ということです。複数の URL がファイルシステムの同じ位置にマップされる + 可能がありますので、そのようなアクセス制御は回避されてしまう可能性が + あります。

+ + いつ <directive + type="section">Location</directive> を使うか + +

Location ディレクティブは + ファイルシステム外のコンテンツにディレクティブを適用するときに + 使用してください。ファイルシステムに存在するコンテンツに対しては、 + Directory と Files を使ってください。 + 例外は、<Location /> で、これはサーバ全体に対して + 設定を適用する簡単な方法です。

+ + +

全ての (プロキシ以外の) リクエストに対し、 + URL は /path/ という、 + 接頭辞 http://servername を含まない形でマッチします。 + プロキシリクエストの場合には、scheme://servername/path + という接頭辞を含む形でマッチし、接頭辞を含めて指定する必要があります。

+ +

URL にはワイルドカードを利用することができます。 + ? は任意の一文字、* は任意の文字列にマッチします。

+ +

~ という文字を追加することで、拡張正規表現を + 利用することもできます。 + 例えば:

+ + + <Location ~ "/(extra|special)/data"> + + +

は URL に /extra/data か /special/data という文字列が + 含まれている場合にマッチします。 + LocationMatch ディレクティブは + Location の正規表現 + 版とまったく同じ動作をします。

+ +

Location 機能は、SetHandler ディレクティブと + 組合わせて利用すると特に便利です。 + 例えば、foo.com のブラウザからのみステータスの参照を有効にしたければ、 + 次のようにすれば良いでしょう。

+ + + <Location /status>
+ + SetHandler server-status
+ Order Deny,Allow
+ Deny from all
+ Allow from .foo.com
+ + </Location> + + +/ (スラッシュ) に関する注 +

スラッシュ文字は、URL 内に現れる場所に応じて変化する + 特別な意味を持っています。 + ファイルシステムにおいて利用する場合には複数のスラッシュでも一つの + スラッシュとして扱われることが多いですが、 + (すなわち、/home///foo は + /home/foo と同じいったように) + URL においては必ずしもそうなるわけではありません。 + LocationMatch + ディレクティブや正規表現を利用した + Location ディレクティブで、 + 複数のスラッシュにマッチさせたいときには、、明示的に記述する + 必要があります。

+ +

例えば、<LocationMatch ^/abc> は、 + /abc というリクエスト URL にマッチしますが、 + //abc というリクエスト URL にはマッチしません。 + (正規表現でない) Location + ディレクティブは、 + proxy リクエストに対して利用する際には同様の振る舞いをしますが、 + (正規表現でない) Location を proxy + でないリクエストに対して利用する際には、 + 一つのスラッシュで複数のスラッシュにマッチします。 + 例えば、<Location /abc/def> と指定し、 + /abc//def というリクエストがあれば、 + マッチすることになります。

 + + +リクエストを受けた際にこれらの異なるセクションが + 組み合わされる方法については + <Directory>, <Location>, <Files> セクションの動作法 + + + +LocationMatch +囲んだディレクティブを正規表現にマッチする URL のみに +適用 +<LocationMatch + regex> ... </LocationMatch> +server configvirtual host + + + +

LocationMatch ディレクティブは、 + Location と同じ様に + URL により中に書かれたディレクティブの適用範囲を制限します。 + 但し、引数は普通の文字列ではなく、正規表現となります。例えば、

+ + + <LocationMatch "/(extra|special)/data"> + + +

は URL に /extra/data か /special/data + という文字列が含まれている場合にマッチします。

+ + +リクエストを受けた際にこれらの異なるセクションが + 組み合わされる方法については + <Directory>, <Location>, <Files> セクションの動作法 + + + +LogLevel +ErrorLog の冗長性を制御する +LogLevel level +LogLevel warn +server configvirtual host + + + +

LogLevel は、エラーログ (ErrorLog ディレクティブを + 見てください) へ記録するメッセージの冗長性を調整します。 + 以下の level を指定でき、順に重要度が下がっていきます。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
レベル 説明 例
emerg 緊急 - システムが利用できないChild cannot open lock file. Exiting + (子プロセスがロックファイルを開けないため終了した)
alert 直ちに対処が必要getpwuid: couldn't determine user name from uid + (getpwuid: UID からユーザ名を特定できなかった)
crit 致命的な状態socket: Failed to get a socket, exiting child + (socket: ソケットが得られないため、子プロセスを終了させた)
error エラーPremature end of script headers + (スクリプトのヘッダが足りないままで終わった)
warn 警告child process 1234 did not exit, sending another SIGHUP + (子プロセス 1234 が終了しなかった。もう一度 SIGHUP を送る)
notice 普通だが、重要な情報httpd: caught SIGBUS, attempting to dump core in ... + (httpd: SIGBUS シグナルを受け、... へコアダンプをした)
info 追加情報"Server seems busy, (you may need to increase + StartServers, or Min/MaxSpareServers)..." (「サーバは負荷が高い、 + (StartServers や Min/MaxSpareServers の値を増やす必要があるかも)」)
debug デバッグメッセージ"Opening config file ..." (設定ファイルを開いている...)
+ +

特定のレベルが指定された場合、それより高いレベルの全てのメッセージが + 報告されます。 + 例えば、LogLevel info に指定すると、 + notice と warn も報告されます。

+ +

なお crit 以上のレベルを指定することが推奨されます。

+ +

例:

+ + + LogLevel notice + + + 注 +

ファイルにログを出力する場合、notice + レベルのメッセージは抑制されず、すべてログに出力されます。 + しかし syslog を使用している場合は、 + これは当てはまりません。

+ + + + + +MaxKeepAliveRequests +持続的な接続上で許可されるリクエストの数 +MaxKeepAliveRequests number +MaxKeepAliveRequests 100 +server configvirtual host + + + +

MaxKeepAliveRequests ディレクティブは、 + KeepAlive が有効な場合に、 + 一回の接続で受け付け可能なリクエストの数を制限します。 + 0 に設定していれば、受け付けるリクエストは無制限になります。 + この設定は、サーバ性能を向上させるために、大きな数値を指定すること勧めます。 +

+ +

例:

+ + + MaxKeepAliveRequests 500 + + + + + +NameVirtualHost +名前ベースのバーチャルホストのための IP アドレスを指定 +NameVirtualHost addr[:port] +server config + + +

NameVirtualHost ディレクティブは、 + 名前ベースのバーチャルホストの設定を行ないたい場合に + 必要となるものです。

+ +

addr にはホスト名を指定できますが、 + 常に IP アドレスを指定するのが推奨されます。 + 例えば、

+ + + NameVirtualHost 111.22.33.44 + + +

NameVirtualHost ディレクティブは、 + 名前ベースのバーチャルホストを + 利用してリクエストを受け付ける IP アドレスを指定します。 + これは、普通は名前ベースのバーチャルホストアドレスです。 + ただし、ファイアーウォールや他のプロキシがリクエストを受け付け、 + 違う IP アドレスのサーバにフォワードするという場合は、 + リクエストを提供したいマシン上の物理インターフェースの + IP アドレスを指定する必要があります。 + 複数のアドレスで複数の名前ベースのバーチャルホストを指定する場合は + 各アドレスに対してディレクティブを書いてください。

+ + 中 +

「主サーバ」や、どの _default_ サーバも、 + NameVirtualHost で指定した IP アドレスへのリクエスト + を処理することはありません (なぜか + NameVirtualHost を + 指定したけどそのアドレスに VirtualHost を定義しなかった場合を除く)。

+ + +

名前ベースのバーチャルホストにポート番号を指定することも可能です。 + 例えば

+ + + NameVirtualHost 111.22.33.44:8080 + + +

IPV6 のアドレスは次の例のように角括弧で囲む必要があります:

+ + + NameVirtualHost [fe80::a00:20ff:fea7:ccea]:8080 + + +

すべてのインタフェースへのリクエストを受け取るようにするためには、 + 引数として * を使います。

+ + + NameVirtualHost * + + + <directive type="section">VirtualHost</directive> ディレクティブの引数 +

VirtualHost ディレクティブの引数は NameVirtualHost ディレクティブの引数に正確に + 合っている必要があることに注意してください。

+ + + NameVirtualHost 1.2.3.4
+ <VirtualHost 1.2.3.4>
+ # ...
+ </VirtualHost>
+ + + + + +バーチャルホスト説明書 + + + + + +Options +ディレクトリに対して使用可能な機能を設定する +Options + [+|-]option [[+|-]option] ... +Options All +server configvirtual host +directory.htaccess + +Options + + +

Options ディレクティブは、特定のディレクトリに対して + どの機能が使用可能かを制御します。

+ +

option を Noneに指定すると、 + 特別な機能は全て無効になります。 + また、以下の示す 1 個以上のものを指定できます。

+ +
+
All
+ +
MultiViews を除いた全ての機能が有効となります。 + これがデフォルトです。
+ +
ExecCGI
+ +
+ mod_cgi による CGI スクリプトの実行を許可します。
+ +
FollowSymLinks
+ +
+ サーバが、このディレクトリ内でシンボリックリンクをたどれるようにします。 +

サーバがシンボリックリンクをたどる場合でも、 + Directory セクションに + マッチさせるための + パス名は変更されません。

+

Location 内に + このオプションを指定しても無視されることに + 注意してください。

+ +
Includes
+ +
+ mod_include が提供する SSI を有効にします。
+ +
IncludesNOEXEC
+ +
+ SSI は有効になりますが、#exec コマンド と #exec CGI は無効になります。 + ただし、#include virtual により、ScriptAlias されたディレクトリで + CGI を実行することは可能です。
+ +
Indexes
+ +
+ もし、URL がディレクトリにマップするリクエストであって、 + 且つ DirectoryIndex で指定したファイル (例えば、index.html) が + ディレクトリ内に無ければ、mod_autoindex が + ディレクトリ内の一覧を整形して返します。
+ +
MultiViews
+ +
+ mod_negotiation による + コンテントネゴシエーション + された "MultiViews" を許可します。
+ +
SymLinksIfOwnerMatch
+ +
+ シンボリック先のファイルまたはディレクトリが、 + シンボリックリンクの所有ユーザ ID と同じ場合にのみシンボリックリンクを + たどれるようにします。 + + 注 Location 内にこのオプションを + 指定しても無視されます。 +
+
+ +

通常、ディレクトリに対して複数の Options が + 適用可能な場合、 + 最も近いもの一つのみが適用され、他のものは無視されます。 + 複数の指定がマージされるわけではありません。(セクションのマージ方法を参照してください。) + しかし、すべての Options ディレクティブが + や - 付きで + 指定された場合はオプションの値はマージされます。 + + を頭につければ現在の設定に加えられ、 + - を付ければ現在の設定から削除されます。

+ +

例えば、+ や - を利用しない場合は:

+ + + <Directory /web/docs>
+ + Options Indexes FollowSymLinks
+ + </Directory>
+
+ <Directory /web/docs/spec>
+ + Options Includes
+ + </Directory> + + +

/web/docs/spec というディレクトリには、 + Includes だけが適用されます。 + しかし、2 番目の Options で + や - を利用してみると:

+ + + <Directory /web/docs>
+ + Options Indexes FollowSymLinks
+ + </Directory>
+
+ <Directory /web/docs/spec>
+ + Options +Includes -Indexes
+ + </Directory> + + +

/web/docs/spec というディレクトリには、 FollowSymLinks と + Includes が適用されます。

+ + 注 +

-IncludesNOEXEC もしくは + -Includes を指定すると、 + 前の設定がどのようになっていようとも SSI は無効となります。

+ + +

どのような設定もされていなければ、デフォルトでは All に + なります。

+ + + + +Require +どの認証済みユーザがリソースをアクセスできるかを選択する +Require entity-name [entity-name] ... +directory.htaccess + +AuthConfig + + +

このディレクティブは、どの認証済みのユーザがディレクトリに + アクセスすることができるかを指定します。 + 以下のような構文になります。

+ +
+
Require user userid [userid] ...
+ +
指定されたユーザのみ、ディレクトリへのアクセスを許可します。
+ +
Require group group-name [group-name] ...
+ +
指定されたグループに属するユーザのみ、ディレクトリへのアクセスを許可します。
+ +
Require valid-user
+ +
全ての認証されたユーザに、ディレクトリへのアクセスを許可します。
+
+ +

Require は、正しく動作するためには AuthName 及び AuthType ディレクティブや、 + (ユーザとグループを指定するために) AuthUserFile 及び AuthGroupFile + といったディレクティブと共に + 指定する必要があります。 + 例えば:

+ + + AuthType Basic
+ AuthName "Restricted Directory"
+ AuthUserFile /web/users
+ AuthGroupFile /web/groups
+ Require group admin + + +

このようにして適用されたアクセス制御は、全てのメソッドに + 対して行なわれます。 + 通常は、これが望ましい動作です。 + もし、特定のメソッドに対してのみアクセスの制御を適用し、 + 他のメソッドは制限しない場合には、Limit セクション内に + Require を + 指定してください。

+ + +Satisfy +mod_authz_host + + + +RLimitCPU +Apache の子プロセスから起動されたプロセスの CPU 消費量を +制限する +RLimitCPU seconds|max [seconds|max] +未設定。オペレーティングシステムのデフォルトを使用 +server configvirtual host +directory.htaccess +All + + +

一つか二つのパラメータをとります。 + 最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、 + 2 番目のパラメータは最大のリソースリミットを設定します。 + パラメータには数字か、オペレーティングシステムの最大となる + max のどちらかを指定することができます。 + 最大のリソースリミットを上げるためには、サーバを + root で実行するか起動されなければいけません。

+ +

ちなみに、この設定は Apache の子プロセス自体ではなく、 + リクエストを受け付けた Apache の子プロセスから fork されたプロセスに + 適用されます。 + これには CGI や SSI から実行されたコマンドが含まれますが、Apache の + 親プロセスから fork されたログのパイププロセスなどには適用されません。

+ +

CPU リソースのリミットはプロセスあたりの秒数で表わされます。

+ + +RLimitMEM +RLimitNPROC + + + +RLimitMEM +Apache の子プロセスから起動されたプロセスのメモリ消費量を +制限する +RLimitMEM bytes|max [bytes|max] +未設定。オペレーティングシステムのデフォルトを使用 +server configvirtual host +directory.htaccess +All + + +

一つか二つのパラメータををとります。 + 最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、 + 2 番目のパラメータは最大のリソースリミットを設定します。 + パラメータには数字か、オペレーティングシステムの最大となる + max のどちらかを指定することができます。 + 最大のリソースリミットを上げるためには、サーバを + root で実行するか起動されなければいけません。

+ +

この設定は Apache の子プロセス自体ではなく、 + リクエストを受け付けた Apache の子プロセスから fork されたプロセスに + 適用されます。 + これには CGI や SSI から実行されたコマンドが含まれますが、Apache の + 親プロセスから fork されたログのパイププロセスなどには適用されません。

+ +

メモリリソースのリミットはプロセスあたりのバイト数で表わされます。

+ +RLimitCPU +RLimitNPROC + + + +RLimitNPROC +Apache の子プロセスから起動されたプロセスが起動するプロセスの +数を制限する +RLimitNPROC number|max [number|max] +未設定。オペレーティングシステムのデフォルトを使用 +server configvirtual host +directory.htaccess +All + + +

一つか二つのパラメータをとります。 + 最初のパラメータは全プロセスに対するリソースのソフトリミットを設定し、 + 2 番目のパラメータは最大のリソースリミットを設定します。 + パラメータには数字か、オペレーティングシステムの最大となる + max のどちらかを指定することができます。 + 最大のリソースリミットを上げるためには、サーバを + root で実行するか起動されなければいけません。

+ +

この設定は Apache の子プロセス自体ではなく、 + リクエストを受け付けた Apache の子プロセスから fork されたプロセスに + 適用されます。 + これには CGI や SSI から実行されたコマンドが含まれますが、Apache の + 親プロセスから fork されたログのパイププロセスなどには適用されません。

+ +

プロセスの制限は、ユーザあたりのプロセス数で制御されます。

+ + 注 +

CGI プロセスがウェブサーバのユーザ ID 以外で実行されるので + 無ければ、 + このディレクティブは、サーバ自身が生成できるプロセスの数を制限することになります。 + そのような状況になっているかどうかは、error_log 中の + cannot fork というメッセージにより + 確認することができます。

+ + +RLimitMEM +RLimitCPU + + + +Satisfy +ホストレベルのアクセス制御とユーザ認証との相互作用を指定 +Satisfy Any|All +Satisfy All +directory.htaccess + +AuthConfig + + +

Allow と + Require の両方が使われているときの + アクセスポリシーを設定します。パラメータは All か Any + です。このディレクティブはある場所へのアクセスがユーザ名/パスワード + とクライアントのホストのアドレスで制限されているときにのみ + 役立ちます。デフォルトの動作 (All) はクライアントがアドレスによる + アクセス制限を満たし、かつ正しいユーザ名とパスワードを入力することを + 要求します。Any では、クライアントはホストの制限を満たすか、 + 正しいユーザ名とパスワードの入力をするかをすればアクセスを許可されます。 + これは、ある場所をパスワードで保護するけれど、特定のアドレスからの + クライアントにはパスワードの入力を要求せずにアクセスを許可する、 + というようなときに使用できます。

+ +

例えば、同じネットワーク上にいる人にはウェブサイトのある部分について + 無制限のアクセスを許したいけれど、外のネットワークの人には + パスワードを提供させるようにするためには、次のような設定をすることが + できます:

+ + + Require valid-user
+ Allow from 192.168.1
+ Satisfy Any + + + + Allow + Require + + + +ScriptInterpreterSource +CGI スクリプトのインタープリタの位置を調べるための手法 +ScriptInterpreterSource Registry|Registry-Strict|Script +ScriptInterpreterSource Script +server configvirtual host +directory.htaccess +FileInfo +Win32 のみ。 +オプション Registry-Strict は Apache 2.0 以降で使用可能 + + +

このディレクティブは、Apache で CGI スクリプトを + 実行する場合に利用するインタープリタを、 + どのように探し出すかについて制御するために使用します。 + デフォルトの設定は Script です。これはスクリプトの + shebang 行 (最初の行で #! から始まるもの) + に指されているインタープリタを使用します。Win32 ではその行は + 以下の様になります。

+ + + #!C:/Perl/bin/perl.exe + + +

もしくは、perl が PATH にある場合は単に:

+ + + #!perl + + +

ScriptInterpreterSource Registry を指定すると、 + スクリプトファイルの拡張子 (例えば、.pl) を + キーとして、Windows のレジストリツリー HKEY_CLASSES_ROOT + を検索するようになります。レジストリのサブキー + Shell\ExecCGI\Command か、それが存在しない場合は + Shell\Open\Command がスクリプトファイルを開くために + 使われます。レジストリキーが見つからないときは、Apache は Script + オプションが指定されたときの動作に戻ります。

+ + セキュリティ +

ScriptInterpreterSource Registry を ScriptAlias されたディレクトリで使うときは + 注意してください。Apache はそのディレクトリ中のすべてのファイルを + 実行しようとします。Registry という設定は通常は実行されない + ファイルに対して望ましくないプログラムの実行が発生する可能性があります。 + 例えば、ほとんどの Windows システムで、 + .htm ファイルのデフォルトの「開く」コマンドは + Microsoft Internet Explorer を実行しますので、スクリプトに指定された + ディレクトリにある .htm ファイルへのリクエストはサーバの + バックグラウンドでブラウザを実行することになります。これは、一分内くらいで + システムをクラッシュさるための良い方法です。

+ + +

Apache 2.0 から導入されたオプション Registry-Strict は + Registry と同じことを行ないますが、サブキー + Shell\ExecCGI\Command のみを使います。 + ExecCGI キーは普通に使われるキーではありません。Windows + レジストリに手動で設定する必要がありますので、システムでの偶発的なプログラムの + 実行を防ぐことができます。

+ + + + +ServerAdmin +サーバがクライアントに送るエラーメッセージに含める電子メールの +アドレス +ServerAdmin email-address +server configvirtual host + + + +

ServerAdmin は、クライアントに返すさまざまな + エラーメッセージ中に記述する、 + 電子メールのアドレスを設定します。

+ +

その際、これのために専用のアドレスを設定するのが良いでしょう。 + 例えば、

+ + + ServerAdmin www-admin@foo.example.com + + +

といったようにします。ユーザはいつもサーバに関する話であるということを + 明記してくるわけではありませんので。

+ + + + + +ServerAlias +リクエストを名前ベースのバーチャルホストにマッチさせているときに +使用されるホストの別名 +ServerAlias hostname [hostname] ... +virtual host + + +

ServerAlias ディレクティブは、ネームベースのバーチャルホストにおいて + 使用するホストの別名を指定します。

+ + + <VirtualHost *>
+ ServerName server.domain.com
+ ServerAlias server server2.domain.com server2
+ # ...
+ </VirtualHost> + + +Apache バーチャルホスト説明書 + + + +ServerName +サーバが自分自身を示すときに使うホスト名とポート +ServerName fully-qualified-domain-name[:port] +server configvirtual host + +このディレクティブはバージョン 2.0 ではバージョン 1.3 の + Port ディレクティブの機能も含みます。 + + +

ServerName ディレクティブは、 + サーバが自分自身を示すホスト名とポートを設定します。 + これは、リダイレクトする URL を生成する際に利用されます。 + 例えば、ウェブサーバを動かしているマシンは simple.example.com + で、DNS のエイリアス www.example.com もあるときに、 + ウェブサーバが後者として認識されて欲しいときは、以下のようにディレクティブを + 使います。

+ + + ServerName www.example.com:80 + + +

ServerName が指定されていないときは、 + サーバは IP アドレスから逆引きを行なうことでホスト名を知ろうとします。 + ServerName にポートが指定されていないときは、サーバはリクエストが来ている + ポートを使います。最高の信頼性と確実性をもたらすためには、 + ServerName を使ってホスト名とポートを明示的に + 指定してください。

+ +

名前ベースのバーチャルホスト + を利用している場合、VirtualHost セクション内の + ServerName はこのバーチャルホストにマッチするために + 何がリクエストの Host: ヘッダに現れる必要があるのかを指定します。

+ +

自己参照 URL (例えば mod_dir モジュールによるものなど) + が指定されたポートを使うか、クライアントのリクエストのポート番号を使うかを + 決定する設定は UseCanonicalName + ディレクティブを参照してください。

+ + +DNS と Apache に関する話 +Apache バーチャルホスト説明書 +UseCanonicalName +NameVirtualHost +ServerAlias + + + +ServerPath +非互換のブラウザが名前ベースのバーチャルホストにアクセスしたときの +ための互換用 URL パス名 +ServerPath URL-path +virtual host + + +

ServerPath ディレクティブは、ネームベースのバーチャルホストにおいて利用する + 互換用 URL パス名を設定します。

+ +Apache バーチャルホスト説明書 + + + +ServerRoot +インストールされたサーバのベースディレクトリ +ServerRoot directory-path +ServerRoot /usr/local/apache +server config + + +

ServerRoot ディレクティブは、 + サーバが存在するディレクトリを設定します。 + 通常、conf/ や logs/ といったサブディレクトリが + 存在します。 + また、他の設定ファイルにおける相対パスは、このディレクトリからとなります。

+ + 例 + ServerRoot /home/httpd + + + + +httpd の -d + オプション +ServerRoot の権限を適切に設定する方法はセキュリティのこつ + + + +ServerSignature +サーバが生成するドキュメントのフッタを設定 +ServerSignature On|Off|EMail +ServerSignature Off +server configvirtual host +directory.htaccess + +All + + +

ServerSignature ディレクティブは、 + サーバが生成するドキュメント + (エラーメッセージ、mod_proxy における FTP のディレクトリリスト、 + mod_info の出力、等々) + の最下行に付与するフッタの設定を行ないます。 + そのようなフッタ行を有効にしたい理由には、 + プロキシが複数連なっている場合に、ユーザはどのサーバが返した + エラーメッセージかを知る手段がほとんど無いというものがあります。

+ + +

デフォルトである Off に設定をすると、フッタ行が抑制されます + (そして、Apache-1.2 以前と互換の動作をします)。 + On に設定した場合は、単にドキュメントの中に、サーバのバージョン、 + 稼動中のバーチャルホストの ServerName の書かれた行を追加し、 + EMail にした場合はさらに参照されたドキュメントに対する ServerAdmin を指す "mailto:" が追加されます。

+ +

バージョン 2.0.44 以降ではこのディレクティブは ServerSignature + ディレクティブにより表示される情報も制御します。

+ +ServerTokens + + + +ServerTokens +Server HTTP 応答ヘッダを設定する +ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full +ServerTokens Full +server config + + +

このディレクティブは、クライアントに送り返す Server + 応答ヘッダ内に、サーバの一般的な OS 種別や、 + コンパイルされて組み込まれているモジュールの情報を + 含めるかどうかを指定します。

+ +
+
ServerTokens Prod[uctOnly]
+ +
サーバは (例えば): Server: + Apache といったように送ります。
+ +
ServerTokens Major
+ +
Server sends (e.g.): Server: + Apache/2
+ +
ServerTokens Minor
+ +
Server sends (e.g.): Server: + Apache/2.0
+ +
ServerTokens Min[imal]
+ +
サーバは (例えば): Server: + Apache/2.0.41 といったように送ります。
+ +
ServerTokens OS
+ +
サーバは (例えば): Server: Apache/2.0.41 + (Unix) といったように送ります。
+ +
ServerTokens Full (もしくは未指定)
+ +
サーバは (例えば): Server: Apache/2.0.41 + (Unix) PHP/4.2.2 MyMod/1.2 といったように送ります。
+
+ +

この設定はサーバ全体に適用され、バーチャルホスト上で有効にしたり + 無効にしたりはできません。

+ +

バージョン 2.0.44 以降ではこのディレクティブは ServerSignature + ディレクティブにより表示される情報も制御します。

+ +ServerSignature + + + +SetHandler +マッチするファイルがハンドラで処理されるようにする +SetHandler handler-name|None +server configvirtual host +directory.htaccess + +FileInfo +Apache 2.0 で core に移動 + + +

.htaccess や Directory + セクション、Location + セクションに書かれた場合、 + このディレクティブはそこにあるすべてのファイルが + handler-name で指定されたハンドラで扱われることを強制します。例えば、拡張子に関わらず、 + ディレクトリ全体がイメージマップファイルとして解析して欲しい場合には、 + 以下をそのディレクトリの .htaccess + ファイルに記述します:

+ + + SetHandler imap-file + + +

別の例: URL http://servername/status + が指定されたときにサーバが状態報告をするようにしたいときは、以下を + httpd.conf に記述します:

+ + + <Location /status>
+ + SetHandler server-status
+ + </Location> + + +

None という値を設定することで、 + 前の方の SetHandler で定義された設定を無効にすることが + できます。

+ + + +AddHandler + + + + +SetInputFilter +クライアントのリクエストや POST の入力を処理するフィルタを設定する +SetInputFilter filter[;filter...] +server configvirtual host +directory.htaccess + +FileInfo + + +

SetInputFilter ディレクティブはクライアントの + リクエストや POST の入力をサーバが受け取ったときに処理するフィルタを + 設定します。これは AddInputFilter + ディレクティブを含め、他の場所で定義されているフィルタの設定に + 追加されます。

+ +

複数のフィルタを指定するときは、データを処理する順番に + セミコロンで区切る必要があります。

+ + +フィルタ説明書 + + + +SetOutputFilter +サーバの応答を処理するフィルタを設定する +SetOutputFilter filter[;filter...] +server configvirtual host +directory.htaccess + +FileInfo + + +

SetOutputFilter ディレクティブは + サーバの応答をクライアントに送り返される前に処理するフィルタを設定します。 + これは AddOutputFilter + ディレクティブを含め、他の場所で定義されているフィルタの設定に + 追加されます。

+ +

例えば、以下の設定は /www/data/ ディレクトリのすべての + ファイルを SSI で処理します。

+ + + <Directory /www/data/>
+ + SetOutputFilter INCLUDES
+ + </Directory> + + +

複数のフィルタを指定するときは、データを処理する順番に + セミコロンで区切る必要があります。

+ +フィルタ説明書 + + + +TimeOut +各イベントについて、リクエストを失敗させるまでにサーバが +待つ時間を設定 +TimeOut seconds +TimeOut 300 +server config + + +

TimeOut ディレクティブは、現在のところ + 以下の三つの待ち時間についての定義を行います:

+ +
    +
  1. GET リクエストを受け取るのにかかる総時間
    2. + +
  2. POST や PUTリクエストにおいて、次の TCP パケットが届くまでの待ち時間
    3. + +
  3. レスポンスを返す際、TCP の ACK が帰ってくるまでの時間
    4. +
+ +

将来には別々の設定をすることが可能にできるよう考慮中です。 + Apache 1.2 以前はタイマーは 1200 がデフォルトでしたが、 + 300 に下げられました。300 でもほとんどの場合は十分すぎる値です。 + コード中の変な場所にまだパケットを送る際にタイマをリセットしない + 場所があるかもしれないので、デフォルトをより小さい値にはしていません。

+ + + + + +UseCanonicalName +サーバが自分自身の名前とポートを決定する方法を設定する +UseCanonicalName On|Off|Dns +UseCanonicalName On +server configvirtual host +directory + + +

多くの状況で Apache は自己参照 URL、すなわち + 同じサーバを指す URL、を作成する必要があります。 + UseCanonicalName On を使うと (1.3 より前の + すべてのバージョンでも) Apache は ServerName ディレクティブと Port + ディレクティブを使ってサーバの正式な名前を作成します。 + この名前がすべての自己参照 URL で使われ、CGI の SERVER_NAME + と SERVER_PORT にも使われます。

+ +

UseCanonicalName Off では Apache は + クライアントがホスト名とポートを提供した場合には自己参照 URL を + それらを元に作成します (提供されていない場合は上で定義されているように + 正式な名前を使います)。 + これらの値は名前ベースの + バーチャルホストを実装するのに使われているのと同じ値で、 + 同じクライアントから取得できる値です。CGI 変数 SERVER_NAME + と SERVER_PORT もクライアントから与えられた値から + 作成されます。

+ +

これが有用な場合の例は、イントラネットのサーバで、www の + ような短い名前でユーザがマシンに接続しているときです。 + ユーザが短い名前を入力して、URL が最後のスラッシュ無しのディレクトリ + へのものであるときに、Apache はリクエストを + http://www.domain.com/splat/ へリダイレクトすることに + 気付くでしょう。認証をするように設定していると、この場合 + ユーザは 2 回認証をしなければならなくなります (www に + 対して 1 回、www.domain.com に対してもう一回 -- + より詳しい情報は この話題の + FAQ を参照してください)。 + しかし、UseCanonicalName が Off になっていると、 + Apache は htttp://www/splat/ にリダイレクトします。

+ +

三つ目のオプション UseCanonicalName DNS は、 + Host: ヘッダを提供しない古いクライアントをサポートした + 大規模な IP ベースのバーチャルホスティングで使用されることを + 意図しています。このオプションでは、Apache はクライアントが + 接続した IP アドレスに DNS の逆引きを行なって自己参照 URL を + 作成します。

+ + 警告 +

CGI が SERVER_NAME に + 関する仮定を行なっているときは、このオプションの設定で動作しなく + なるかもしれません。クライアントは実質的にはホスト名にとして + 何でも望みの値を指定することができます。CGI が + SERVER_NAME のみを使って自己参照 URL を作成している + 場合はどの設定を行なっても大丈夫なはずです。

 + +ServerName +Listen + + + +VirtualHost +特定のホスト名や IP アドレスのみに適用されるディレクティブを +囲む +<VirtualHost + addr[:port] [addr[:port]] + ...> ... </VirtualHost> +server config + + +

VirtualHost 及び + </VirtualHost> は、 + 特定のバーチャルホストに対してのみ適用されるディレクティブ群を括る + ために使われます。 + バーチャルホストコンテキストで許可される全てのディレクティブを指定可能です。 + サーバが、指定されたバーチャルホストにあるドキュメントへの + リクエストを受け付けた場合、 + VirtualHost セクションの中にある + ディレクティブが適用されます。 + Addrは、次のものが利用できます:

+ +
    +
  • バーチャルホストの IP アドレス
    • + +
  • バーチャルホストの IP に対応する完全なドメイン名
    • + +
  • NameVirtualHost * と共に使われる、 + すべての IP アドレスにマッチする文字 *
    • + +
  • IP ベースのバーチャルホストで他のものにマッチしない IP アドレス + のための文字列 _default_
    • +
+ + 例 + <VirtualHost 10.1.2.3>
+ + ServerAdmin webmaster@host.foo.com
+ DocumentRoot /www/docs/host.foo.com
+ ServerName host.foo.com
+ ErrorLog logs/host.foo.com-error_log
+ TransferLog logs/host.foo.com-access_log
+ + </VirtualHost> + + +

IPv6 アドレスはオプションのポート番号の指定と区別するために、 + 角括弧で括って指定する必要があります。次は IPv6 の例です:

+ + + <VirtualHost [fe80::a00:20ff:fea7:ccea]>
+ + ServerAdmin webmaster@host.example.com
+ DocumentRoot /www/docs/host.example.com
+ ServerName host.example.com
+ ErrorLog logs/host.example.com-error_log
+ TransferLog logs/host.example.com-access_log
+ + </VirtualHost> + + +

各々のバーチャルホストにはそれぞれ違う IP アドレス、ポート番号 + もしくはホスト名に対応する必要があり、 + 1 番目の場合には複数のアドレスで IP パケットを受信できるように + サーバマシンを設定しなければなりません。 + (もし、マシンが複数のネットワークインターフェースと持たない場合は、 + (OSがサポートしていれば) ifconfig alias コマンドにより + 達成できます)。

+ +

:port といった形式で記述することにより、 + マッチさせるポートを変更可能です。 + この指定をしない場合には、主サーバ設定における + 一番最後に Port で指定されたポートが + デフォルトとなります。 + :* を指定することにより、 + アドレス上の全てのポートにマッチします。(_default_ のときは + これを使うことが推奨されています。)

+ +

セキュリティに関して: + サーバーを起動した以外のユーザがログファイルが保管されるディレクトリに + 書き込み可能なときになぜセキュリティが破られる可能性があるかの詳細は + セキュリティに関するコツ を + 参照してください。

+ + 注意点 +

VirtualHost は Apache が Listen する + IP アドレスには影響を与えません。 + Listen を + 使って Apache が正しいアドレスを listen するように設定する必要があります。

+ + +

IP ベースのバーチャルホストを使っている場合は、特別な名前 + _default_ を指定することができます。その場合は + そのバーチャルホストは他のバーチャルホストで明示的に挙げられていない + すべての IP アドレスにマッチします。_default_ バーチャルホストが無い + 場合に IP がバーチャルホストで指定されたものにマッチしないときは、 + VirtualHost セクションの外のすべての定義からなる「主」サーバ設定が + 使われます。(ただし、NameVirtualHost ディレクティブにマッチする + すべての IP アドレスは「主」サーバ設定も _default_ バーチャルホストも + 使わないことに注意してください。詳しくは ネームベースのバーチャルホスト を + 参照してください。)

+ +

:port といった形式で記述することにより、 + マッチさせるポートを変更可能です。 + この指定をしない場合には、主サーバ設定における + 一番最後に Listen で指定された + ポートがデフォルトとなります。 + :* を指定することにより、 + アドレス上の全てのポートにマッチします。(_default_ のときは + これを使うことが推奨されています。)

+ +

:port といった形式で記述することにより、 + マッチさせるポートを変更可能です。 + この指定をしない場合には、主サーバ設定における + 一番最後に Port で指定されたポートが + デフォルトとなります。 + :* を指定することにより、 + アドレス上の全てのポートにマッチします。(_default_ のときは + これを使うことが推奨されています。)

+ + セキュリティ +

サーバーを起動した以外のユーザがログファイルが保管されるディレクトリに + 書き込み可能なときになぜセキュリティが破られる可能性があるかの詳細は + セキュリティに関するコツ を + 参照してください。

 + +Apache バーチャルホスト説明書 +DNS と Apache に関する話 +Apache が使用するアドレスとポートの設定 +リクエストを受けた際にこれらの異なるセクションが + 組み合わされる方法については + <Directory>, <Location>, <Files> セクションの動作法 + + + diff --git a/docs/manual/mod/core.xml.meta b/docs/manual/mod/core.xml.meta index ee601d200c..15f5ff3381 100644 --- a/docs/manual/mod/core.xml.meta +++ b/docs/manual/mod/core.xml.meta @@ -8,5 +8,6 @@ de en + ja -- 2.50.1