From: Yoshiki Hayashi Date: Mon, 30 Sep 2002 09:26:40 +0000 (+0000) Subject: New Japanese translations. X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=fcc9f9d1337ce70ea5e20359893889c38ebb71b7;p=apache New Japanese translations. Forward port from 1.3. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97025 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_cgi.xml.ja b/docs/manual/mod/mod_cgi.xml.ja new file mode 100644 index 0000000000..aee5440b46 --- /dev/null +++ b/docs/manual/mod/mod_cgi.xml.ja @@ -0,0 +1,213 @@ + + + + + + +mod_cgi +CGI スクリプトの実行 +Base +mod_cgi.c +cgi_module + + + + + + +

Mime タイプが application/x-httpd-cgi + であるか、ハンドラ cgi-script (Apache 1.1 以降) + が指定されているファイルは CGI スクリプトとして扱われ、 + サーバにより実行され、その出力がクライアントに返されます。 + ファイルは、AddType + ディレクティブに指定された 拡張子を名前に含むか、 + ScriptAlias + ディレクトリに存在することによりこのタイプになります。

+ +

サーバが CGI スクリプトを実行するときには、 + DOCUMENT_ROOT + と呼ばれる変数を環境に追加します。この変数は + DocumentRoot + の値を保持します。

+ +

Apache で CGI スクリプトを使用するためのイントロダクションは、 + CGI による動的コンテンツ + を参照してください。

+ +

Unix でマルチスレッドの MPM を使っている場合は、このモジュールの + 代わりに mod_cgid を使う必要があります。 + ユーザレベルではこの二つのモジュールは本質的には同一です。

+ + +Options +ScriptAlias +AddHandler + +
CGI 環境変数 +

サーバは CGI + 規格 で決められている CGI + 環境変数を設定します。以下のものは、条件付きで設定されます。

+ +
+
PATH_INFO
+ +
これは AcceptPathInfo ディレクティブが明示的に off + に設定されている場合は設定されません。デフォルトの、AcceptPathInfo が + 指定されていないときの振る舞いでは、mod_cgi はパス情報 + (URI のスクリプトのファイル名の後に続く /more/path/info) を + 受け付けますが、コアはサーバはパス情報のあるリクエストに + 対して 404 NOT FOUND エラーを返します。AcceptPathInfo ディレクティブを + 省略すると、mod_cgi へのリクエストに対して on を + 設定したのと同じ効果になります。
+ +
REMOTE_HOST
+ +
HostnameLookups + が on (デフォルトでは off です) + で、アクセスしているホストのアドレスの DNS + の逆引きが実際にホスト名を見つけたときにのみ設定されます。
+ +
REMOTE_IDENT
+ +
IdentityCheck + が on に設定されていて、アクセスしているホストが + ident プロトコルをサポートしているときにのみ設定されます。 + これは簡単に偽ることができ、クライアントとサーバの間に + プロキシがあればまったく役に立たないので、 + この変数の値は信用できないということに注意してください。 +
+ +
REMOTE_USER
+ +
CGI + スクリプトに認証が必要なときにのみ設定されます。
+
+
+ +
CGI のデバッグ +

CGI スクリプトのデバッグは、正しく動作していないスクリプトの出力 + (標準出力とエラー) + を調べることができないために、難しい状態が続いていました。 + これらの Apache 1.2 以降にある + ディレクティブはより詳細なエラーのログ収集を提供します。

+ +
CGI ログファイルの書式 +

設定されているときには、CGI エラーログは適切に動作しないすべての + CGI をログ収集します。それぞれの正しく動作しない CGI + スクリプトは 複数の行にわたる情報がログ収集されます。最初の + 2 行は常に以下の書式です:

+ + %% [time] request-line
+ %% HTTP-status CGI-script-filename + +

エラーが、CGI スクリプトが実行できないというものである場合は、 + ログファイルはさらにもう 2 行書かれます:

+ + %%error
+ error-message + +

そうではなく、エラーが正しくないヘッダ情報を返す結果である場合 + (スクリプトのバグであることがよくあります)、 + 以下の情報がログ収集されます:

+ + %request
+ 受け取ったすべての HTTP リクエストヘッダ
+ (もしあれば) POST や PUT の中身
+ %response
+ CGI スクリプトにより出力されたすべてのヘッダ
+ %stdout
+ CGI 標準出力
+ %stderr
+ CGI 標準エラー
+ +

(スクリプトが標準出力や標準エラーに何も出力しなかった場合は、 + %stdout や %stderr はありません)。

+
+
+ + +ScriptLog +CGI スクリプトのエラーログファイルの場所 +ScriptLog file-path +サーバ設定ファイル +バーチャルホスト + +mod_cgimod_cgid + + + +

ScriptLog ディレクティブは CGI スクリプトの + エラーログファイルを設定します。ScriptLog が設定されていないときは、 + エラーログは作成されません。設定されているときは、CGI + のエラーはすべて引数として与えられているファイル名にログされます。 + 相対パスで指定されているときは、 + ServerRootからの相対パスとして扱われます。

+ + 例 + ScriptLog logs/cgi_log + + +

このログは子プロセスが実行されているユーザとしてオープンされます。 + すなわち、User ディレクティブ + で指定された + ユーザです。これは、スクリプトログが書かれるディレクトリがそのユーザで + 書き込み可能か、スクリプトファイルが手動で作成され、そのユーザで + 書き込み可能になっている必要があるということです。スクリプトログを + アクセスログなどのためのログディレクトリに書かれるようにしたときは、 + そのディレクトリを子プロセスを実行しているユーザの権限で + 書き込み可能にはしないようにしてください。

+ +

スクリプトのログ収集は CGI スクリプトを書くときの + デバッグ用の機能として意図されていて、通常のサーバで + 常に使用されるようには意図されていないということに注意してください。 + 速度や効率は最適化されておらず、設計された以外の方法で使用されると + セキュリティの問題があるかもしれません。

+ + + + +ScriptLogLength +CGI スクリプトのログファイルの大きさの上限 +ScriptLogLength bytes +ScriptLogLength 10385760 +サーバ設定ファイル +バーチャルホスト + +mod_cgimod_cgid + + + +

ScriptLogLength は CGI スクリプトのログファイル + の大きさを制限するために使用することができます。ログファイルは + CGI のエラー毎に大量の情報 (リクエストのすべてのヘッダ、 + すべての出力)をログしますので、すぐに大きなファイルになります。 + この大きさの制限がないことによる問題を防ぐために、 + このディレクティブを使って CGI のログファイルの + 最大のファイルサイズを設定することができます。 + ファイルがこの大きさを超えた場合は、それ以上は書き込まれません。

+ + + + +ScriptLogBuffer +スクリプトログに記録される PUT や POST リクエストの内容の上限 +ScriptLogBuffer bytes +ScriptLogBuffer 1024 +サーバ設定ファイル +バーチャルホスト + +mod_cgimod_cgid + + + +

大きな本体を受け取ったときにログファイルがすぐに大きくなりすぎる + 問題を避けるために、ファイルにログ収集される PUT と POST + の本体の大きさは制限されています。デフォルトでは、1024 + バイトまでがログ収集されますが、 + このディレクティブはそれを変更することができます。 +

+ + + + diff --git a/docs/manual/mod/mod_info.xml.ja b/docs/manual/mod/mod_info.xml.ja new file mode 100644 index 0000000000..0923805acc --- /dev/null +++ b/docs/manual/mod/mod_info.xml.ja @@ -0,0 +1,83 @@ + + + + + + +mod_info +サーバの設定の包括的な概観を提供する +Extension +mod_info.c +info_module + + + + +

mod_info を設定するには、以下を httpd.conf + ファイルに加えます。

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

サーバ設定の情報へのアクセスを制限するために、 + <location> + ディレクティブの中に <Limit> + 節を入れるとよいかもしれません。

+ +

一旦設定すると、http://your.host.dom/server-info + をアクセスすることでサーバの情報を得られるようになります。

+ + +

このモジュールは実行時に設定ファイルを読み込みます。 + サーバの設定ファイルが最後にサーバに読み込まれた後に変更されている + 場合には、表示されている内容は実行されているサーバの設定を反映して + いないかもしれないことに注意してください。 + また、設定ファイルはサーバが実行されているユーザの権限で + 読み込み許可が与えられている必要があります + (User + ディレクティブを参照してください)。 + でなければ、ディレクティブの設定は表示されません。

+ +

mod_info + がサーバに組み込まれている場合は、ディレクトリ毎のファイル + (例えば、.htaccess) を含むすべての設定ファイルで + ハンドラを使用可能であるということにも注意してください。 + これは、あなたのサイトではセキュリティに関連した問題があるかもしれません。 +

+ +

特に、このモジュールはシステムパス、ユーザ名/パスワード、 + データベース名など、他の Apache モジュールの設定ディレクティブから + セキュリティ上微妙な情報を漏らす可能性があります。 + このモジュールの動作方法のせいで、情報の流出を防ぐ方法はありません。 + ですから、このモジュールはちゃんとアクセスが制御された環境で、 + 注意して使ってください。

+ + + + +AddModuleInfo +server-info ハンドラにより表示されるモジュールの情報に +追加の情報を付け加える +AddModuleInfo module-name string +サーバ設定ファイル +バーチャルホスト +Apache 1.3 以降 + + +

これは、string の内容がモジュール module-name + の追加情報 として HTML + として解釈され、表示されるようにします。例:

+ + +AddModuleInfo mod_auth.c 'See <A \
+ HREF="http://www.apache.org/docs/mod/mod_auth.html">\
+ http://www.apache.org/docs/mod/mod_auth.html</A>' + + + + + + diff --git a/docs/manual/mod/mod_negotiation.xml.ja b/docs/manual/mod/mod_negotiation.xml.ja new file mode 100644 index 0000000000..992f47f14e --- /dev/null +++ b/docs/manual/mod/mod_negotiation.xml.ja @@ -0,0 +1,262 @@ + + + + + + +mod_negotiation +コンテントネゴシエーション + 機能を提供する +Base +mod_negotiation.c +negotiation_module + + +

コンテントネゴシエーション、より正確にはコンテンツの選択機能は、 + 複数用意されているドキュメントから、クライアントの能力に一番合った + ドキュメントを選択する機能です。この実装は二つあります。

+ +
    +
  • タイプマップ (type-map + ハンドラで扱われるファイル)。これは variants + を含んでいるファイルを明示的に指定します。
    • + +
  • MultiViews の探索 (MultiViews Option で使用するようになります)。 + サーバが暗黙の内にファイル名のパターンマッチを行ない、 + その結果から選択します。
    • +
+ + +DefaultLanguage +AddEncoding +AddLanguage +AddType +MultiViewsMatch + +
タイプマップ +

タイプマップは RFC 822 のメールヘッダと同じ書式です。 + ドキュメントの記述が空行で分離されて書かれていて、ハッシュ文字 + ('#') で始まる行はコメントとして扱われます。 + ドキュメントの説明は複数のヘッダレコードから構成されます。 + レコードは、続きの行が空白で始まっていると複数の行にまたがります。 + 最初の空白が消去されて、前の行とつなげて 1 行として扱われます。 + ヘッダレコードはキーワード名の後に値が続くという形式で、 + キーワード名は常にコロンで終わります。空白はヘッダ名と値の間、 + 値のトークンの間に入れることができます。 + 使用可能なヘッダは以下のとおりです:

+ +
+
Content-Encoding:
+
ファイルのエンコーディング。Apache は AddEncoding ディレクティブ + で定義されたエンコーディングだけを認識します。通常 compress + されたファイルのための x-compress と gzip + されたファイルのための x-gzip を含みます。 + エンコーディングの比較をするときは、接頭辞 x- + は無視されます。
+ + +
Content-Language:
+ +
インターネット標準の言語タグ (RFC 1766) + で定義されている言語の種類。例えば、en + は英語を表します。
+ +
Content-Length:
+ +
ファイルの長さ (バイト数)。 + このヘッダがない場合、ファイルの実際の長さが使用されます。
+ +
Content-Type:
+ +
ドキュメントの MIME + メディアタイプ、オプショナルなパラメータ付き。パラメータの構文は + name=value + で、メディアタイプや他のパラメータとはセミコロンで分離されます。 + 共通のパラメータは以下のとおり: + +
+
level
+ +
メディアタイプのバージョンを示す整数。 + text/html では 2 がデフォルトで、その他の場合は + 0 がデフォルトです。
+ +
qs
+ +
クライアントの能力に関係なく、variant + を他と比較したときの相対的な「品質」で、0.0 から 1.0 + の範囲の浮動点小数。 + 例えば、写真を表現しようとしているときは普通は JPEG + ファイルの方が ASCII ファイルよりも高い品質になります。 + しかし、リソースが ASCII アートで表現されているときは、ASCII + ファイルの方が JPEG + ファイルよりも高い品質になります。このように、qs + はリソース毎に特有の値を取ります。 +
+
+ 例: + +Content-Type: image/jpeg; qs=0.8 +
+ +
URI:
+ +
(指定のメディアタイプ、コンテントエンコーディングの) variant の + ファイルの uri. これは、マップファイルからの相対 URL として + 解釈されます。同じサーバに存在しなければならず、クライアントが + 直接リクエストしたときにアクセスを許可されるものでなければなりません。
+ +
Body:
+ +

Apache 2.0 で新設されたこの Body ヘッダを使って、 + リソースの実際の内容をタイプマップファイルに書くことができます。 + このヘッダは本文の内容の区切りとなる文字列で始まる必要があります。 + タイプマップファイルの続く行は、区切り文字列が見つかるまで、 + リソースの本文になります。

+ +

例:

+ +Body:----xyz----
+<html>
+<body>
+<p>Content of the page.</p>
+</body>
+</html>
+----xyz---- + +
+
+
+ +
+ MultiViews + +

MultiViews 探索は、Multiviews Options ディレクティブにより有効になります。 + サーバが /some/dir/foo + へのリクエストを受け取り、/some/dir/foo が存在 + しない場合、サーバはディレクトリを読んで、 + foo.* にあてはまる全てのファイルを探し、 + 事実上それらのファイルをマップするタイプマップを作ります。 + そのとき、メディアタイプとコンテントエンコーディングは、 + そのファイル名を直接指定したときと同じものが割り当てられます。 + それからクライアントの要求に一番合うものを選び、 + そのドキュメントを返します。

+
+ + +CacheNegotiatedDocs +コンテントネゴシエーションされたドキュメントをプロキシサーバが +キャッシュできるようにする +CacheNegotiatedDocs on|off +CacheNegotiatedDocs off +サーバ設定ファイル +バーチャルホスト + +バージョン 2.0で構文が変わりました + + +

このディレクティブが設定されていると、コンテントネゴシエーション + をした結果のドキュメントのキャッシュを許可します。 + これは、プロキシの後ろにいるクライアントが能力に一番合った + ドキュメントではなく、 + キャッシュをより効果的にするものを得る可能性があるということです。

+ +

このディレクティブは HTTP/1.0 ブラウザからのリクエスト + のみに適用されます。HTTP/1.1 は、 + 交渉されたドキュメントのキャッシュに対してずっとよい制御が可能なので、 + このディレクティブは HTTP/1.1 のリクエストには影響しません。

+

2.0 より前のバージョンでは、 + CacheNegotiatedDocs は引数を取らず、 + ディレクティブが存在することで on の動作をしていました。

+ + + + +ForceLanguagePriority +要求に合う単独のドキュメントが見つからなかったときに行なうことを指定 + +ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback] +ForceLanguagePriority Prefer +サーバ設定ファイル +バーチャルホスト +ディレクトリ +.htaccess + +FileInfo +バージョン 2.0.30 以降で使用可能 + + +

ForceLanguagePriority ディレクティブは + 要求に合うドキュメントを一つだけ返すことができないときに、 + LanguagePriority + ディレクティブを使ってネゴシエーションの結果を返します。

+ +

ForceLanguagePriority Prefer は、同等の選択肢が + いくつかあるときに、HTTP の 300 (MULTIPLE CHOICES) を返す代わりに、 + LanguagePriority を使って一つだけドキュメントを返すように + します。以下のディレクティブが指定されていて、ユーザの Accept-Language + ヘッダでは en と de の品質が共に .500 (同じくらい許容) であるときは、 + 最初にマッチする variant の en が送られます。

+ + + LanguagePriority en fr de
+ ForceLanguagePriority Prefer + + +

ForceLanguagePriority Fallback は、HTTP 406 + (NOT ACCEPTABLE) の代わりにドキュメントを送ります。 + 以下のディレクティブが指定されていて、ユーザの Accept-Language は + es 言語のみを許可していて、さらにそのような variant がないときには、 + 以下の LanguagePriority のリストの最初の variant が送れれます。

+ + + LanguagePriority en fr de
+ ForceLanguagePriority Fallback + + +

Prefer と Fallback の両方のオプションを同時に指定することができます。 + ですから、複数の variant があるときは LanguagePriority の最初の + variant が送られ、クライアントの許容言語に合う vaiant がないときは + 存在するドキュメントで最初のものが送られる、という様にすることができます。

+ + + + +LanguagePriority +クライアントが優先度を示さなかったときの言語の variant の優先度を +指定 +LanguagePriority MIME-lang [MIME-lang] ... +サーバ設定ファイル +バーチャルホスト +ディレクトリ +.htaccess + +FileInfo + + +

LanguagePriority は、MultiViews + リクエストを扱うときに、クライアントが優先順位を提供していない場合の + 言語の優先順位を設定します。MIME-lang + のリストが優先度の降順に並びます。 + 例:

+ +LanguagePriority en fr de + +

foo.html がリクエストされ、foo.html.fr + と foo.html.de が両方存在し、 + ブラウザが言語の優先順位を提供してない場合は + foo.html.fr が返されます。

+ +

このディレクティブは他の方法で「最善」 + の言語が決定できないときか、ForceLanguagePriority ディレクティブが + None 以外のときにのみ効果があることに注意してください。 + HTTP/1.1 リクエストが正しく実装されている場合には、 + このディレクティブは無効になります。

+ + + + diff --git a/docs/manual/mod/mod_setenvif.xml.ja b/docs/manual/mod/mod_setenvif.xml.ja new file mode 100644 index 0000000000..18662452ce --- /dev/null +++ b/docs/manual/mod/mod_setenvif.xml.ja @@ -0,0 +1,243 @@ + + + + + + +mod_setenvif +リクエストの特徴に基づいた環境変数の設定を可能にする +Base +mod_setenvif.c +setenvif_module + + +

mod_setenvif + モジュールは、リクエストのある側面が指定された正規表現 + に合うかどうかによって環境変数を設定する機能を提供します。 + これらの環境変数を使用して、サーバの他の部分がどのような動作をするかを + 決定することができます。

+ +

このモジュールが提供するディレクティブは、 + 設定ファイルに現れる順番に適用されます。 + それを使って、次の例のようにより複雑な設定をすることができます。 + これは、ブラウザが mozilla ではあるけれど、MSIE ではないときに + netscape を設定します。

+ + BrowserMatch ^Mozilla netscape
+ BrowserMatch MSIE !netscape
+ + + +Apache の環境変数 + + +BrowserMatch +HTTP User-Agent に基づいて環境変数を設定する + +BrowserMatch regex [!]env-variable[=value] +[[!]env-variable[=value]] ... +サーバ設定ファイル +バーチャルホストディレクトリ +.htaccess +FileInfo + + +

BrowserMatch は + SetEnvIf ディレクティブの + 特例で、User-Agent HTTP リクエストヘッダに基づいて + 環境変数を設定します。以下の 2 行の効果は同じになります:

+ + + BrowserMatchNoCase Robot is_a_robot
+ SetEnvIfNoCase User-Agent Robot is_a_robot
+ + +

その他の例:

+ + BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
+ BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
+ BrowserMatch MSIE !javascript
+ + + + + +BrowserMatchNoCase +HTTP User-Agent に基づいて大文字小文字を区別せずに +環境変数を設定する +BrowserMatchNoCase regex [!]env-variable[=value] + [[!]env-variable[=value]] ... +サーバ設定ファイル +バーチャルホストディレクトリ +.htaccess +FileInfo +Apache 1.2 以降 + (Apache 1.2 ではこのディレクティブはもう用いられていない + mod_browser モジュールにありました) + + + +

BrowserMatchNoCase ディレクティブは + 意味的には BrowserMatch ディレクティブと + 同じです。ただし、このディレクティブは大文字小文字を区別しない + マッチングを行ないます。例えば:

+ + + BrowserMatchNoCase mac platform=macintosh
+ BrowserMatchNoCase win platform=windows
+ + +

BrowserMatch ディレクティブと + BrowserMatchNoCase ディレクティブは + SetEnvIf ディレクティブと + SetEnvIfNoCase ディレクティブの + 特例です。以下の 2 行の効果は同じです:

+ + + BrowserMatchNoCase Robot is_a_robot
+ SetEnvIfNoCase User-Agent Robot is_a_robot
+ + + + + +SetEnvIf +リクエストの属性に基づいて環境変数を設定する + +SetEnvIf attribute + regex [!]env-variable[=value] + [[!]env-variable[=value]] ... +サーバ設定ファイル +バーチャルホストディレクトリ +.htaccess +FileInfo + + +

SetEnvIf + ディレクティブは、リクエストの属性に基づいて環境変数を定義します。 + 最初の引数で指定できる attribute は以下の三つのどれかです:

+ +
    +
  1. HTTP リクエストヘッダフィールド (詳しい情報は RFC 2616 を + 参照してください)。例えば、Host, + User-Agent, Referer, + Accept-Language です。リクエストヘッダの集合を現すために + 正規表現を使うこともできます。
    2. + +
  2. 以下のリクエストの一部分のどれか: + +
      +
    • Remote_Host - + リクエストを行なっているクライアントのホスト名 (もしあれば)
      • + +
    • Remote_Addr - + リクエストを行なっているクライアントの IP アドレス
      • + +
    • Remote_User - + 認証されたユーザ名 (もしあれば)
      • + +
    • Request_Method - + 使用されているメソッド名 (GET, POST + など)
      • + +
    • Request_Protocol - + リクエストが行なわれたプロトコルの名前とバージョン + (例えば、"HTTP/0.9", "HTTP/1.1" など。)
      • + +
    • Request_URI - + URL のスキームとホストの後の部分
      • +
    +
    3. + +
  3. リクエストと関連付けられる環境変数のリスト。これにより +SetEnvIf ディレクティブが以前のマッチの結果を +使うことができるようになります。この方法のテストでは前の部分にある +SetEnvIf[NoCase] の結果のみを使用可能です。「前」とは、 +より広い範囲に対して定義されている (サーバ全体のように) か、現在のディレクティブの +範囲でより前の部分で定義されているか、ということです。 +環境変数である可能性は、リクエストの特性に対するマッチが存在せず、 +attribute に正規表現が使われなかったときにのみ考慮されます。
    4. +
+ +

二つ目の引数 (regex) は Perl 互換の正規表現です。 +これは POSIX.2 の egrep 形式の正規表現と似ています。regex が +attribute にマッチする場合は、残りの引数が評価されます。

+ +

残りの引数は設定する変数の名前で、設定される値を指定することもできます。 +これは、

+ +
    +
  1. varname か
    2. + +
  2. !varname か
    3. + +
  3. varname=value
    4. +
+ +

のどれかの形式になります。

+ +

最初の形式では、値は "1" に設定されます。二つ目は、 + もし値が定義されていればそれを取り除き、三つ目は変数を + value として与えられた値に設定します。

+ + +例: + SetEnvIf Request_URI "\.gif$" object_is_image=gif
+ SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
+ SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
+ :
+ SetEnvIf Referer www\.mydomain\.com intra_site_referral
+ :
+ SetEnvIf object_is_image xbm XBIT_PROCESSING=1
+ :
+ SetEnvIf ^TS* ^[a-z].* HAVE_TS
+ + +

初めの三つはリクエストが画像であるときに環境変数 + object_is_image を設定します。四つ目は + 参照元のページがウェブサイト www.mydomain.com にあるときに + intra_site_referral を設定します。

+ +

最後の例は、リクエストに "TS" で始まり、値が集合 [a-z] のどれかで + 始まるヘッダがあるときに HAVE_TS を設定します。

+ + +他の例は、Apache の環境変数 + + + + +SetEnvIfNoCase +リクエストの属性に基づいて大文字小文字を区別せずに環境変数を設定する +SetEnvIfNoCase attribute regex + [!]env-variable[=value] + [[!]env-variable[=value]] ... +サーバ設定ファイル +バーチャルホストディレクトリ +.htaccess +FileInfo +Apache 1.3 以降 + + + +

SetEnvIfNoCase は意味的には + SetEnvIf ディレクティブと + 同じです。違いは、正規表現のマッチングが大文字小文字を区別しないで + 行なわれることです。例えば:

+ + + SetEnvIfNoCase Host Apache\.Org site=apache + + +

これは HTTP リクエストヘッダにフィールド Host: が + あり、その値が Apache.Org や apache.org、 + その他の大文字小文字の組み合わせであったときに site + 環境変数を "apache" に設定します。

+ + + + diff --git a/docs/manual/mod/mod_speling.xml.ja b/docs/manual/mod/mod_speling.xml.ja new file mode 100644 index 0000000000..5d78e634ae --- /dev/null +++ b/docs/manual/mod/mod_speling.xml.ja @@ -0,0 +1,93 @@ + + + + + + +mod_speling +ユーザが入力したであろう間違った URL を、 +大文字小文字の区別を無視することと一つ以下の綴り間違いを許容することで +修正を試みる +Extension +mod_speling.c +speling_module + + + + +

リクエストの綴りが間違っていたり、 + 大文字小文字が違っていたりするために、Apache のコアサーバが + ドキュメントへのリクエストへの応答を正しく提供できないことがあります。 + このモジュールは、他のすべてのモジュールがあきらめた後であったとしても、 + リクエストに合うドキュメントを見つけようとすることによりこの問題の + 解決を試みます。このモジュールはリクエストされたディレクトリにある + それぞれのドキュメントの名前と、リクエストされたドキュメントの名前とを + 大文字小文字の区別を無視し、一文字までの + 綴りの間違い (文字の挿入/省略/隣合う文字の置換、間違った文字) + を許可して比較することにより、目的を達成しようとします。 + この方法でリクエストに合うドキュメントの一覧が作成されます。

+ +

ディレクトリをスキャンした後に、

+ +
    +
  • 適切なドキュメントが見つからなかった場合、 + Apache はいつもと同じように処理をし、 + 「ドキュメントが見つからない」というエラーを返します。
    • + +
  • リクエストに「ほとんど」合うドキュメントが一つだけ見つかった場合、 + それがリダイレクト応答として返されます。
    • + +
  • よく似たドキュメントが複数見つかった場合、 + そのリストがクライアントに返され、 + クライアントが正しい候補を選択できるようにします。
    • +
+ + + + +CheckSpelling +spelling モジュールを使用するようにする +CheckSpelling on|off +CheckSpelling Off + +サーバ設定ファイル +バーチャルホスト +ディレクトリ +.htaccess + +Options +CheckSpelling は Apache 1.1 では別配布のモジュールで、 +大文字小文字の間違いのみの機能でした。Apache 1.3 で Apache の配布に +含まれるようになりました。Apache 1.3.2 より前では CheckSpelling +ディレクティブは「サーバ」と「バーチャルホスト」コンテキストでのみ +使用可能でした + + + +

このディレクティブは綴り用のモジュールを使用するかどうかを + 決めます。使用時には、以下のことを覚えておいてください

+ +
    +
  • 同時にたくさんの綴りの訂正を行なわなければならないときは、 + そのために行なわれるディレクトリのスキャンがサーバの性能に + 影響を与えます。
    • + +
  • ドキュメントの中に綴りの「訂正」により + 意図せず合ってしまうような重要なファイルがないようにしてください。 +
    • + +
  • モジュールはユーザ名の綴りの間違い + (http://my.host/~apahce/ のように) + を訂正することはできません。 + 訂正できるのはファイル名とディレクトリ名だけです。
    • + +
  • 綴りの訂正は存在するファイルに厳密に適用されますので、 + <Location /status> + はネゴシエーションの結果のファイル "/stats.html" + として間違って扱われるかもしれません。
    • +
+ + + + + diff --git a/docs/manual/mod/mod_unique_id.xml.ja b/docs/manual/mod/mod_unique_id.xml.ja new file mode 100644 index 0000000000..b0b86b9365 --- /dev/null +++ b/docs/manual/mod/mod_unique_id.xml.ja @@ -0,0 +1,181 @@ + + + + + + +mod_unique_id +それぞれのリクエストに対する一意な識別子の入った環境変数を +提供する +Extension +mod_unique_id.c +unique_id_module + + + +

このモジュールは非常に制限された条件下で、 + それぞれのリクエストに「すべて」のリクエストに対して + 一意に決まることが保証されている魔法のトークンを提供します。 + この一意な識別子は、適切に設定されたクラスタでは複数の + マシンの間でさえも一意になります。それぞれのリクエストに対して環境変数 + UNIQUE_ID に識別子が設定されます。 + 一意な識別子が便利な理由はいろいろありますが、 + このドキュメントの目的からは外れるため、ここでは説明しません。

+ + +
+ 理論 + +

まずはじめに、Apache サーバが Unix + マシンでどのように動作をするかを簡単に説明します。 + この機能は現時点では Windows NT ではサポートされていません。 + Unix マシンでは Apache はいくつかの子プロセスを作成し、 + その子プロセスが一つずつリクエストを処理します。それぞれの子プロセスは、 + 生存期間中に複数のリクエストを扱うことができます。 + この議論では子プロセス間では一切データを共有しないことにします。 + 以後、この子プロセスのことを httpd プロセスと呼びます。

+ +

あなたのウェブサイトにはあなたが管理するいくつかのマシンがあるとします。 + それらをまとめてクラスタと呼ぶことにします。それぞれのマシンは複数の + Apache を実行することもできます。 + これらすべてをまとめたものが「宇宙」であると考えられます。 + いくつかの仮定の下で、クラスタのマシン間がたくさん通信をすることなく、 + この宇宙の中でそれぞれのリクエストに一意な識別子を生成できることを示します。 +

+ +

クラスタにあるマシンは以下の要求を見たさなければなりません。 + (マシンが一つだけだとしても、NTP で時計を合わせる方が良いです。)

+ +
    +
  • NTP や他のネットワーク上で時間を合わせるプロトコルによって + 各マシンの時間の同期が取られていること。
    • + +
  • モジュールがホスト名を引いて違う IP + アドレスを受け取ることができるように、 + クラスタのそれぞれのマシンのホスト名が違うこと。
    • +
+ +

オペレーティングシステムにおいては、pid (プロセス ID) が + 32 ビットの範囲内であることを仮定します。オペレーティングシステムの + pid が 32 ビットを超える場合は、簡単な修正ではありますが、 + コードを変更する必要があります。

+ +

これらの仮定が満たされていると、ある時点において、 + クラスタ内のどのマシンのどの httpd + プロセスでも、一意に同定することができます。これはマシンの IP + アドレスと httpd プロセスの pid で十分に行なうことができます。 + ですから、リクエストに一意な識別子を生成するためには、 + 時刻を区別する必要があるだけです。

+ +

時刻を区別するために、Unix のタイムスタンプ (UTC の 1970 年 + 1 月 1 日からの秒数) と、16 ビットのカウンタを使います。 + タイムスタンプの粒度は一秒ですので、一秒間の 65536 + までの値を表現するためにカウンタを使用します。四つの値 + ( ip_addr, pid, time_stamp, counter ) で各 httpd + プロセスで一秒の間に 65536 リクエストを数えあげることができます。 + 時間が経つと pid が再利用されるという問題がありますが、 + この問題を解決するためにカウンタが使用されます。

+ +

httpd の子プロセスが作成されると、カウンタは + (その時点のマイクロ秒 ÷ 10) modulo 65536 で初期化されます + (この式はいくつかのシステムにある、マイクロ秒の + タイマの下位ビットが異なるという問題を解決するために選ばれました)。 + 一意な識別子が生成されたとき、使用されるタイムスタンプは + ウェブサーバにリクエストが到着した時刻になります。 + カウンタは識別子が生成されるたびに増加します + (あふれた場合は 0 に戻ります)。

+ +

カーネルはプロセスをフォークすると、それぞれのプロセスのために + pid を生成します。pid は繰り返されることが許可されています + (pid の値は多くの Unix では 16 ビットですが、新しいシステムでは + 32 ビットに拡張されています)。 + ですから、ある程度の時間が経過すると同じ pid が再び使用されます。 + しかし、一秒内に再使用されなければ、 + 四つの値の一意性は保たれます。つまり、我々はシステムが一秒間 + に 65536 個のプロセスを起動しないと仮定しています (いくつかの Unix + では 32768 プロセスですが、それですらほとんどあり得ないでしょう)。

+ +

何らかの理由で、同じ時刻が繰り返されたとしましょう。 + つまり、システムの時計が狂っていて、もう一度過去の時刻になってしまった + (もしくは進みすぎていたときに、 + 正しい時刻に戻したために再び将来の時刻になってしまった) とします。 + この場合、pid とタイムスタンプが再使用されることが簡単に示されます。 + カウンタ初期化用の関数は、この問題の回避を手助けしようと選択されています。 + 本当はカウンタの初期化をするためにランダムな数字を使いたいのですが、 + ほとんどのシステムでは簡単に使用できる数は無いことに注意してください + (すなわち、rand ()は使えません。rand () には seed + を与える必要があり、seed には時刻を使えません。一秒単位では、 + その時刻はすでに繰り返されているからです)。 + これは、完璧な対策ではありません。

+ +

この対策はどのくらい効果があるでしょうか? + ここでは、マシン群の中の一つは最大で一秒に 500 + リクエストを扱うと仮定します (これを書いている時点では妥当な上限です。 + 通常システムがすることは静的なファイルを取りだすだけではありませんから)。 + それを行なうために、そのマシンは並行して来るクライアントの数に + 応じた数の子プロセスを要求します。 + しかしながら、悲観的に考えて、一つの子プロセスが一秒に 500 + リクエストを扱えるとします。そうすると、(一秒の精度において) + 時刻が同じ時を繰り返すと、この子プロセスがカウンタの値を再び使い、 + 一意性が壊れる可能性が 1.5% あります。 + これは非常に悲観的な例で、実世界の値では、ほとんど起こりそうにありません。 + それでもこれが起こる可能性のあるようなシステムなら、 + (プログラムコードを編集して) + カウンタを 32 ビットにするのが良いでしょう。 +

+ +

サマータイムにより時計が「戻される」ことを気にしている人が + いるかもしれません。ここで使用される時間は UTC であり、 + それは「常に」進むのでここでは問題になりません。x86 上の Unix + はこの条件を満たすために適切な設定が必要かもしれないことに + 注意してください。マザーボードの時計は UTC になっていて、 + 他の時間はそこから適切に補正されることを仮定できるように + 設定されなければなりません。そのような場合でさえ、NTP + を使っているならばリブート後にすぐ正しい UTC の時間になるでしょう。

+ +

UNIQUE_ID 環境変数は 112 ビット (32 ビット IP + アドレス、32 ビット pid, 32 ビットタイムスタンプ、16 + ビットカウンタの四つの組) をアルファベット [A-Za-z0-9@-] + を用いて MIME の base64 符号化と同様の方法により符号化し、19 + の文字を生成することにより作成されます。MIME の base64 + のアルファベットは実際は [A-Za-z0-9+/] ですが、 + + と / とは URL + では特別な符号化が必要なので、あまり望ましくありません。 + 全ての値はネットワークバイトオーダで符号化されますので、 + 符号は違ったバイトオーダのアーキテクチャ間で比較可能です。 + 実際の符号化の順番は: タイムスタンプ、IP アドレス、pid, + カウンタです。この順には目的がありますが、 + アプリケーションは符号を解析するべきではないことを強調しておきます。 + アプリケーションは符号化された UNIQUE_ID + 全体を透過的なトークンとして扱うべきです。 + UNIQUE_ID は他の UNIQUE_ID + との等価性を調べるためだけにのみ使用できます。

+ +

この順番は将来、既存の UNIQUE_ID + のデータベースとの衝突を心配することなく符号を変更することが + 可能になるように選択しています。 + 新しい符号はタイムスタンプを最初の要素として残すのが望ましく、 + それ以外は同じアルファベットとビット長を使うことができます。 + タイムスタンプは本質的に増加系列ですので、 + クラスタの全てのマシンがリクエストとサーバ機能を停止して、 + 古い符号化方式を使用するのをやめるフラグ秒があれば十分です。 + その後は、リクエストを再開し、 + 新しい符号を発行することができるようになります。

+ +

我々はこれが、 + この問題に対する比較的移植性の高い解決法だと考えています。 + Windows NT のようなマルチスレッドのシステムに拡張することができますし、 + 将来必要になればさらに増やすこともできます。 + ID は必要に応じて長くすることができますので、生成された ID + は実質上、無限に有効です。また、クラスタのマシン間の通信も事実上必要なく + (NTP による同期のみが必要で、これはオーバヘッドはあまりありません)、httpd + プロセス間の通信も必要ありません (通信はカーネルにより割り当てられた + pid の値により暗黙の内に行なわています)。 + さらに限られた状況下では、ID はさらに短くすることができますが、 + より多くの情報を仮定する必要がでてきます (例えば、32 ビット + IP アドレスはどのサイトにおいても過剰な情報ですが、 + それの代わりになる移植性のあるものはありません)。

+
+ + +