From bcadc4945e200d34b4cf973548106f30022c6f8d Mon Sep 17 00:00:00 2001 From: Yoshiki Hayashi Date: Thu, 29 Aug 2002 06:45:39 +0000 Subject: [PATCH] Update transformations. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96562 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/content-negotiation.html.ja.jis | 320 ++++++++++---------- docs/manual/filter.html.ja.jis | 94 ++---- docs/manual/invoking.html.ja.jis | 108 ++----- docs/manual/mod/core.html.en | 20 +- docs/manual/mpm.html.ja.jis | 83 +++-- 5 files changed, 263 insertions(+), 362 deletions(-) diff --git a/docs/manual/content-negotiation.html.ja.jis b/docs/manual/content-negotiation.html.ja.jis index c991db61e6..1fc3239d03 100644 --- a/docs/manual/content-negotiation.html.ja.jis +++ b/docs/manual/content-negotiation.html.ja.jis @@ -1,43 +1,30 @@ - - +コンテントネゴシエーション - Apache HTTP Server
[APACHE DOCUMENTATION]

Apache HTTP Server Version 2.0

コンテントネゴシエーション

- - - - Apache コンテントネゴシエーション - - - - - - - -

コンテントネゴシエーション

- -

Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを +

Apache は HTTP/1.1 の規格に記述されているコンテントネゴシエーションを サポートしています。 - ブラウザにより提供されたメディアタイプ、 - 言語、文字セット、エンコーディングの優先傾向に基づいて、 + ブラウザにより提供されたメディアタイプ、 + 言語、文字セット、エンコーディングの優先傾向に基づいて、 最適なリソースの表現を選択できます。 また、不完全なネゴシエーション情報を送ってくるブラウザからのリクエストを もっと賢く取り扱えるよう、いくつか機能も実装してあります。

-

コンテントネゴシエーションは mod_negotiation - モジュールにより +

コンテントネゴシエーションは + mod_negotiation + モジュールによって 提供されていて、デフォルトで組み込まれています。

-
- -

コンテントネゴシエーションについて

+

コンテントネゴシエーションについて

リソースは、幾つか異なった表現で利用できる場合があります。 - 例えば、異なる言語や異なるメディアタイプ、 + 例えば、異なる言語や異なるメディアタイプ、 またはそれらの組み合わせで利用できるかも知れません。 もっとも適した選択をする方法の一つには、インデックスページを ユーザに見せて、ユーザに選んでもらう方法があります。 - しかし、サーバが自動的に選ぶことができる場合が多くあります。 + しかし、サーバが自動的に選ぶことができる場合が多くあります。 これは、ブラウザがリクエスト情報毎の情報の一部に、 どの表現を嗜好するかを送ることで動作しています。 例えばブラウザは、可能ならフランス語で情報を見たい、 @@ -45,9 +32,8 @@ 自分の嗜好を知らせることができます。 ブラウザはリクエストのヘッダで自分の優先傾向を知らせます。 フランス語のみの表現を要求する場合は、ブラウザは次を送ります。

-
-  Accept-Language: fr
-
+ +
Accept-Language: fr

この優先傾向は、選択可能な表現が存在して、 言語によって様々な表現がある場合にのみ適用される @@ -58,23 +44,24 @@ そして様々なメディアタイプを受け付けるが、 プレインテキストや他のタイプよりは HTML を好む、 他のメディアタイプよりは GIF や JPEG を好む、しかし最終手段として - 他のメディアタイプも受け付ける、と設定されています。

-
-  Accept-Language: fr; q=1.0, en; q=0.5
-  Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6,
-        image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
-
- Apache は HTTP/1.1 規格で定義されている 'server + 他のメディアタイプも受け付ける、と設定されています。

+ +
+ Accept-Language: fr; q=1.0, en; q=0.5
+ Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1 +
+ +

Apache は HTTP/1.1 規格で定義されている 'server driven' コンテントネゴシエーションをサポートしています。 Accept, Accept-Language, Accept-Charset, Accept-Encoding リクエストヘッダを完全にサポートしています。Apache は 'transparent' コンテントネゴシエーションもサポートしていますが、 - これは RFC 2295 と RFC 2296 で定義されている実験的な + これは RFC 2295 と RFC 2296 で定義されている試験的な ネゴシエーションプロトコルです。 これらの RFCで定義されている 'feature negotiation' - はサポートしていません。 + はサポートしていません。

-

リソースとは URI +

リソースとは URI で特定される概念上のもののことです (RFC 2396)。 Apache のような HTTP サーバは、その名前空間の中での リソースの表現へのアクセスを提供します。 @@ -88,8 +75,7 @@ ネゴシエーション可能なリソースの variant が異なる、 その状態を指して、 ネゴシエーションの次元と呼びます。

- -

Apache におけるネゴシエーション

+

Apache におけるネゴシエーション

リソースをネゴシエーションするためには、 サーバは variant それぞれについての情報を知っておく必要があります。 @@ -106,7 +92,7 @@ 行なってその結果から選択する方法。 -

type-map ファイルを使う

+

type-map ファイルを使う

タイプマップは type-map ハンドラ (もしくは、古い Apache @@ -118,10 +104,8 @@ として定義するようなハンドラを、 設定ファイル中に置く必要があることに注意してください。 これは

-
-  AddHandler type-map .var
-
- をサーバ設定ファイル中に書くことが一番良い方法です。 +
AddHandler type-map .var
+

をサーバ設定ファイル中に書くことが一番良い方法です。

タイプマップファイルは記述するリソースと同じ名前を持っていて、 利用可能な variant それぞれのエントリを持っている必要があります。 @@ -132,35 +116,37 @@ (しかしこれは必須ではなく、あったとしても無視されるものです)。 次に例を示します。このファイルはリソース foo を記述しているので、foo.var という名前になります。

-
-  URI: foo
-
-  URI: foo.en.html
-  Content-type: text/html
-  Content-language: en
-
-  URI: foo.fr.de.html
-  Content-type: text/html;charset=iso-8859-2
-  Content-language: fr, de
-
- たとえ MultiViews を使用するようになっていたとしても、 + +
+ URI: foo
+
+ URI: foo.en.html
+ Content-type: text/html
+ Content-language: en
+
+ URI: foo.fr.de.html
+ Content-type: text/html;charset=iso-8859-2
+ Content-language: fr, de
+
+

たとえ MultiViews を使用するようになっていたとしても、 ファイル名の拡張子よりタイプマップの方が優先権を持つということにも 注意してください。 variant の品質が違うときは、この画像のように (JPEG, GIF, ASCII アートがあります) メディアタイプの "qs" - パラメータで指定されます。 -

-  URI: foo
-
-  URI: foo.jpeg
-  Content-type: image/jpeg; qs=0.8
-
-  URI: foo.gif
-  Content-type: image/gif; qs=0.5
-
-  URI: foo.txt
-  Content-type: text/plain; qs=0.01
-
+ パラメータで指定されます。

+ +
+ URI: foo
+
+ URI: foo.jpeg
+ Content-type: image/jpeg; qs=0.8
+
+ URI: foo.gif
+ Content-type: image/gif; qs=0.5
+
+ URI: foo.txt
+ Content-type: text/plain; qs=0.01
+

qs 値の範囲は 0.000 から 1.000 です。qs 値が 0.000 の variant は決して @@ -182,15 +168,18 @@ ドキュメントにあります。

-

Multiviews

+

Multiviews

MultiViews はディレクトリ毎のオプションで、 - <Directory>, <Location>, - <Files> や、(AllowOverride + <Directory>, + <Location>, + <Files> + や、(AllowOverride が適切な値に 設定されていると) .htaccess - ファイルで Options - ディレクティブによって設定することができます。Options - AllMultiViews + ファイルで Options + ディレクティブによって設定することができます。 + Options All は + MultiViews をセットしないことに注意してください。明示的に その名前を書く必要があります。

@@ -206,38 +195,37 @@ 直接指定したときと同じものが割り当てられます。 それからクライアントの要求に一番合うものを選びます。

-

サーバがディレクトリの索引を作ろうとしていると、 +

サーバがディレクトリの索引を作ろうとしている場合、 MultiViews - は DirectoryIndex + は DirectoryIndex ディレクティブで指定されたファイルを探す過程にも 適用されます。設定ファイルに

-
-  DirectoryIndex index
-
- が書かれていて、index.html と +
DirectoryIndex index
+

が書かれていて、index.htmlindex.html3 が - 両方存在していると、サーバはその中から毎回どちらかを適当に選びます。 + 両方存在していると、サーバはその中からどちらかを適当に選びます。 もしその両方が存在せずに index.cgi - が存在していると、 サーバはそれを実行します。 + が存在していると、 サーバはそれを実行します。

もしディレクトリを読んでいる際に、 文字セット、コンテントタイプ、言語、エンコーディングを 指定するための mod_mime で認識できる拡張子を持たないファイルが見つかると、結果は - MultiViewsMatch + MultiViewsMatch ディレクティブの設定に依存します。このディレクティブは ハンドラ、フィルタ、他のファイル拡張子タイプのどれが MultiViews ネゴシエーションで使用できるかを決定します。

-

ネゴシエーション方法

- Apache はリソースの variant の一覧を、タイプマップファイルか +

ネゴシエーション方法

+ +

Apache はリソースの variant の一覧を、タイプマップファイルか ディレクトリ内のファイル名からかで取得した後、 「最適な」 variant を決定するために二つの方法の どちらかを起動します。 Apache のコンテントネゴシエーションの機能を使うために、 どのようにしてこの調停が行われるか詳細を知る必要はありません。 しかしながら、この文書の残りでは関心のある人のために、 - 使用されている方法について説明しています。 + 使用されている方法について説明しています。

ネゴシエーション方法は二つあります。

@@ -246,8 +234,8 @@ driven negotiation が使用されます。Apache のアルゴリズムは後に詳細に説明されています。 このアルゴリズムが使用された場合、Apache - はより良い結果になるように、特定の次元において品質の値を - 「変える」ことができます。Apache + はより良い結果になるように、特定の次元において品質の値を + 「変える」ことができます。Apache が品質の値を変える方法は後で詳細に説明されています。
  • RFC 2295 @@ -261,7 +249,7 @@ を実行するように頼むことができます。
  • -

    ネゴシエーションの次元

    +

    ネゴシエーションの次元

    @@ -271,7 +259,7 @@ - + - + - + - +
    メディアタイプメディアタイプ ブラウザは Accept ヘッダフィールドで優先傾向を指定します。 @@ -281,7 +269,7 @@
    言語言語 ブラウザは Accept-Language ヘッダフィールドで優先傾向を指定します。 @@ -291,7 +279,7 @@
    エンコーディングエンコーディング ブラウザは Accept-Encoding ヘッダフィールドで優先傾向を指定します。 @@ -299,7 +287,7 @@
    文字セット文字セット ブラウザは Accept-Charset ヘッダフィールドで優先傾向を指定します。 @@ -309,7 +297,8 @@
    -

    Apache ネゴシエーションアルゴリズム

    + +

    Apache ネゴシエーションアルゴリズム

    ブラウザに返す「最適な」variant を (もしあれば) 選択するように Apache は次のアルゴリズムを使うことができます。 @@ -340,7 +329,8 @@

  • 言語品質数値が最高の variant を選びます。
  • (もしあれば) Accept-Language ヘッダの言語順か、 - (もしあれば) LanguagePriority + (もしあれば) + LanguagePriority ディレクティブの言語順で最適な言語の variant を選びます。
  • 最高「レベル」のメディアパラメータ @@ -386,7 +376,7 @@ ブラウザやキャッシュはこの情報を使うことができます)。 以上で終わり。
  • -
  • ここに来たということは、variant が一つも選択されなかった +
  • ここに来たということは、variant が一つも選択されなかった (ブラウザが許容するものがなかったため) ということです。 406 ステータス ("No Acceptable representation" を意味する) が、利用可能な variant のリストのついた HTML @@ -394,8 +384,7 @@ 相違の次元を示す HTTP Vary ヘッダも設定されます。
  • -

    品質の値を変える

    - +

    品質の値を変える

    上記の Apaceh ネゴシエーションアルゴリズムの厳格な解釈で 得られるであろう値から、Apache は品質数値を時々変えます。 @@ -407,39 +396,40 @@ ブラウザが完全で正しい情報を送っていれば、 この数値変化は適用されません。

    -

    メディアタイプとワイルドカード

    +

    メディアタイプとワイルドカード

    Accept: リクエストヘッダはメディアタイプの優先傾向を指定します。 これはまた、"image/*" や "*/*" といった「ワイルドカード」メディアタイプを含むことができます。 ここで * は任意の文字列にマッチします。 ですから、次の:

    -
    -  Accept: image/*, */*
    -
    - を含むリクエストは、"image/" ではじまるタイプ全てが許容できる、 + +
    Accept: image/*, */*
    + +

    を含むリクエストは、"image/" ではじまるタイプ全てが許容できる、 そして他のどんなタイプも許容できる (この場合はじめの "image/*" は冗長になります) ことを示します。 扱うことのできる明示的なタイプに加えて、機械的に - ワイルドカードを送るブラウザもあります。例えば: -

    +    ワイルドカードを送るブラウザもあります。例えば:

    + +
    Accept: text/html, text/plain, image/gif, image/jpeg, */* - - こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、 +
    +

    こうすることの狙いは、明示的にリストしているタイプが優先されるけれども、 異なる表現が利用可能であればそれでも良い、ということです。 しかしながら、上の基本的なアルゴリズムでは、 */* ワイルドカードは他の全てのタイプと全く同等なので優先されません。 ブラウザは */* にもっと低い品質 (優先) - 値を付けてリクエストを送るべきなのです。例えば: -

    +    値を付けてリクエストを送るべきなのです。例えば:

    +
    Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01 - - 明示的なタイプには品質数値が付けられていませんので、 +
    +

    明示的なタイプには品質数値が付けられていませんので、 デフォルトの 1.0 (最高値) の優先になります。 ワイルドカード */* は低い優先度 0.01 を与えられているので、 明示的にリストされているタイプに合致する variant がない場合にのみ、 - 他のタイプが返されます。 + 他のタイプが返されます。

    もし Accept: ヘッダが q 値を全く含んでいなければ、 望みの挙動をするために、 @@ -451,7 +441,8 @@ 正しい情報を送るブラウザからのリクエストは期待通りに 動作するようになります。

    -

    言語ネゴシエーションの例外処理

    + +

    言語ネゴシエーションの例外処理

    Apache 2.0 では新たに、言語ネゴシエーションが適合するものを 見つけるのに失敗した時に、優雅にフォールバックできるような @@ -465,10 +456,10 @@ このような場合には Apache が Accept-Language を無視して、 クライアントのリクエストに明示的には合致しないドキュメントを 提供するように設定できます。 - ForceLanguagePriority + ForceLanguagePriority ディレクティブは、これらのエラーの一つか両方をオーバーライドするために 使用できて、 - LanguagePriority + LanguagePriority ディレクティブの内容を使ってサーバの判断を代行するようにできます。

    サーバは他に適合するものが見つからなければ、 @@ -484,8 +475,9 @@ ですが不幸なことに、多くのクライアントではデフォルトで このような設定になっています。) しかしながら、他の言語にはマッチせず、"No Acceptable Variants" - エラーを返したり、 LanguagePriority にフォールバック - しようとしているときは、 + エラーを返したり、 + LanguagePriority + にフォールバックしようとしているときは、 サブセット指定を無視して、en-GBen にマッチします。 Apache はクライアントの許容言語リストに暗黙に @@ -497,22 +489,22 @@ 適切に設定されたクライアントともきちんと動作するために 必要です。

    - -

    Transparent Content Negotiation の拡張

    - Apache は transparent content negotiation プロトコル - (RFC 2295) を次のように拡張しています。 - 特定のコンテントエンコーディングのみが利用可能である variant - に印を付けるために、新たに {encoding ..} - 要素を variant リスト中に使っています。 - リスト中のエンコードされた variant を認識し、 - Accept-Encoding リクエストヘッダに従って許容される - エンコードをもった variant は、どれでも候補 variant - として使用するように、 - RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。 - RVSA/1.0 の実装では、最適な variant が見つかるまで、 - 計算した品質数値は小数点以下 5 桁まで丸めません。 - -

    リンクと名前の変換に関する注意点

    +

    Transparent Content Negotiation +の拡張

    + +

    Apache は transparent content negotiation プロトコル +(RFC 2295) を次のように拡張しています。 +特定のコンテントエンコーディングのみが利用可能である variant +に印を付けるために、新たに {encoding ..} +要素を variant リスト中に使っています。 +リスト中のエンコードされた variant を認識し、 +Accept-Encoding リクエストヘッダに従って許容される +エンコードをもった variant は、どれでも候補 variant +として使用するように、 +RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。 +RVSA/1.0 の実装では、最適な variant が見つかるまで、 +計算した品質数値は小数点以下 5 桁まで丸めません。

    +

    リンクと名前の変換に関する注意点

    言語ネゴシエーションを使っている場合は、 ファイルが一つ以上の拡張子を持てて、 @@ -522,10 +514,10 @@ 幾つかの異なる名前の変換を選べることになります。

    典型的なファイルでは、MIME タイプ拡張子 (例えば - html) を持っていて、エンコーディング拡張子 - (例えば gz) を持っているかもしれなくて、 + html) を持っていて、エンコーディング拡張子 + (例えば gz) を持っているかもしれなくて、 このファイルに異なる言語 variant を用意していれば、 - もちろん言語拡張子 (例えば en) + もちろん言語拡張子 (例えば en) を持っているでしょう。

    例:

    @@ -552,7 +544,7 @@ foo.html.en - foo
    + foo
    foo.html - @@ -569,10 +561,10 @@ foo.html.en.gz - foo
    + foo
    foo.html - foo.gz
    + foo.gz
    foo.html.gz @@ -581,16 +573,16 @@ foo - foo.html
    - foo.html.gz
    + foo.html
    + foo.html.gz
    foo.gz foo.gz.html.en - foo
    - foo.gz
    + foo
    + foo.gz
    foo.gz.html foo.html @@ -599,29 +591,28 @@ foo.html.gz.en - foo
    - foo.html
    + foo
    + foo.html
    foo.html.gz foo.gz -

    上の表を見て、拡張子なしのリンク (例えば foo) +

    上の表を見て、拡張子なしのリンク (例えば foo) がいつでも使えることに気が付くでしょう。 この利点は、ドキュメントとして応答するファイルの 実際のファイルタイプを隠蔽して、リンクの参照を変更することなく 後からファイルを変更できる、 - 例えば html から shtml - に、あるいは cgi に変更できる点です。

    + 例えば html から shtml + に、あるいは cgi に変更できる点です。

    リンクに MIME タイプを使い続けたい (例えば - foo.html)時は、言語拡張子は + foo.html)時は、言語拡張子は (エンコーディング拡張子もあればそれも含めて) MIME タイプ拡張子の右側になければなりません - (例えば foo.html.en)。

    - -

    キャッシュに関する注意事項

    + (例えば foo.html.en)。

    +

    キャッシュに関する注意事項

    キャッシュが一つの表現を保存しているときは、 リクエスト URL と関連づけられています。 @@ -639,21 +630,16 @@

    HTTP/1.0 準拠のクライアントからのリクエストに対しては、 (ブラウザであろうとキャッシュであろうと) ネゴシエーションを受けた応答のキャッシュを許すために、 - CacheNegotiatedDocs ディレクティブを使用できます。 + CacheNegotiatedDocs + ディレクティブを使用できます。 このディレクティブは、サーバ設定ファイルやバーチャルホストに書くことができ、 引数をとりません。 HTTP/1.1 クライアントからのリクエストには効力を持ちません。

    - -

    追加情報

    +

    追加情報

    コンテントネゴシエーションに関する追加情報は、 - Alan J. Flavell さんのLanguage + Alan J. Flavell さんのLanguage Negotiation Notes をご覧下さい。ですが、 Apache 2.0 での変更点を含むためには更新されていないかもしれない ということに注意してください。

    - - - - - +

    Apache HTTP Server Version 2.0

    索引ホーム \ No newline at end of file diff --git a/docs/manual/filter.html.ja.jis b/docs/manual/filter.html.ja.jis index d7ef281c12..8d7734cb75 100644 --- a/docs/manual/filter.html.ja.jis +++ b/docs/manual/filter.html.ja.jis @@ -1,79 +1,43 @@ - - - - - - - フィルタ - Apache HTTPD - - - - - - - -

    フィルタ

    - - - - - - - -
    関連モジュール
    -
    - mod_deflate
    - mod_ext_filter
    - mod_include
    -
    関連ディレクティブ
    -
    - AddInputFilter
    - AddOutputFilter
    - ExtFilterDefine
    - ExtFilterOptions
    - SetInputFilter
    - SetOutputFilter
    -
    - +フィルタ - Apache HTTP Server
    [APACHE DOCUMENTATION]

    Apache HTTP Server Version 2.0

    フィルタ

    +

    Apache でのフィルタの使い方について記述しています。

    +

    フィルタ

    + +
    関連モジュール

    mod_deflate
    mod_ext_filter
    mod_include
    関連ディレクティブ

    AddInputFilter
    AddOutputFilter
    ExtFilterDefine
    ExtFilterOptions
    SetInputFilter
    SetOutputFilter
    +

    フィルタ とは、サーバが送受信したデータに 適用される処理プロセスのことをいいます。クライアントからサーバに - 送られたデータは 入力フィルタ によって、サーバから + 送られたデータは 入力フィルタ によって、サーバから クライアントに送られるデータは出力フィルタによって 処理されます。複数のフィルタを適用することができ、 その順番を厳密に指定することもできます。

    -

    Apache 内部では、チャンク (データのぶつ切り) を行ったり、 +

    Apache 内部では、チャンク (データのぶつ切り) を行ったり、 バイト範囲の指定されたリクエストを扱ったりといった機能を 行う際に、フィルタが使われています。それに加えて、 実行時の設定ディレクティブで選択が可能なフィルタを モジュールが提供できます。 - データに適応されるフィルタのセットは、 SetInputFilter, - SetOutputFilter, AddInputFilter, - AddOutputFilter ディレクティブで制御できます。

    + データに適応されるフィルタのセットは、 + SetInputFilter, + SetOutputFilter, + AddInputFilter, + AddOutputFilter + ディレクティブで制御できます。

    現行の Apache HTTP サーバの配布では、 次のユーザ選択可能なフィルタが提供されています。

    -
    -
    INCLUDES
    mod_includeで Server-Side Include をします。
    -
    DEFLATE
    mod_deflate を使って、 -クライアントに送信する前に出力を圧縮します。
    -
    - -

    また、mod_ext_filter モジュールで - 外部プログラムをフィルタとして指定することができます。

    - - - - - +
    +
    INCLUDES
    +
    mod_include で Server-Side Include をします。
    +
    DEFLATE
    +
    mod_deflate + を使って、クライアントに送信する前に出力を圧縮します。
    +
    + +

    また、mod_ext_filter モジュールで + 外部プログラムをフィルタとして指定することができます。

    +

    Apache HTTP Server Version 2.0

    索引ホーム \ No newline at end of file diff --git a/docs/manual/invoking.html.ja.jis b/docs/manual/invoking.html.ja.jis index c2749a7445..7a3b8a80b7 100644 --- a/docs/manual/invoking.html.ja.jis +++ b/docs/manual/invoking.html.ja.jis @@ -1,58 +1,24 @@ - - - - - - - Starting Apache - - - - - - - -

    Apache の起動

    - - -
    - -

    Windows - での Apache の起動

    - -

    Windows 上では、Apache は通常は - Windows NT ではサービスとして、Windows 95 - ではコンソールアプリケーションとして実行されます。 +Apache の起動 - Apache HTTP Server

    [APACHE DOCUMENTATION]

    Apache HTTP Server Version 2.0

    Apache の起動

    +

    Windows 上では、Apache は通常は + Windows NT ではサービスとして、Windows 95 + ではコンソールアプリケーションとして実行されます。 詳細に関しては、「 Windows で Apache を実行する」をご覧下さい。

    -

    Unix - での Apache の起動

    -

    Unixでは、httpd - プログラムが、リクエスト処理をバックグラウンドで常に動作する - デーモンとして実行されます。

    + プログラムが、バックグラウンドで常にリクエスト処理を行う + デーモンとして実行されます。この文書ではどのように + httpd を起動するかについて記述しています。

    +

    Apache の起動方法

    もし、設定ファイル中で指定されている - Listen + Listen がデフォルトの 80 (もしくは 1024 以下の他のポート) - である場合は、Apache を起動するためには root + である場合は、Apache を起動するためには root 権限が必要になりますが、 これはこの特権ポートにバインドするためです。 起動して、一度ログファイルを開くといった準備のための @@ -60,46 +26,41 @@ listen と応答を実際に行うプロセスを起動します。 メインの httpd プロセスは root 権限で走り続けますが、 子プロセスはもっと低い権限で走ります。 - これは選択したマルチプロセッシングモジュールで制御されます。

    + これは選択したマルチプロセッシングモジュールで制御されます。

    httpd が起動されてまず最初にすることは、 - 設定ファイル httpd.conf - の位置を特定して読み込むことです。 + 設定ファイル + httpd.conf の位置を特定して読み込むことです。 このファイルの位置はコンパイル時に設定されますが、実行時に -f コマンドラインオプションを使って 位置を指定することもできます。例えば次のようにです。

    -
    - /usr/local/apache/bin/httpd -f - /usr/local/apache/conf/httpd.conf -
    +
    /usr/local/apache/bin/httpd -f + /usr/local/apache/conf/httpd.conf

    httpd のバイナリを直接起動する代わりに、 apachectl - と呼ばれるシェルスクリプトが提供されています。 + というシェルスクリプトが提供されています。 apachectl startapachectl stop といった簡単なコマンドで、 デーモンプロセスを制御するのに使えます。

    -

    スタートアップが万事上手くいったら、サーバはターミナルから +

    スタートアップが万事上手くいったら、サーバはターミナルから 切り離されて、コマンドプロンプトが即座に戻ってくるでしょう。 これはサーバが起動している状態を示しています。 その後はブラウザでサーバに接続して、 - DocumentRoot + DocumentRoot ディレクトリのテストページやそこからリンクされている ローカルのドキュメントを見ることができるでしょう。

    +

    起動時のエラー

    -

    スタートアップ時のエラー -

    - -

    Apache は、スタートアップ時に致命的な問題に遭遇すると、 +

    Apache は、起動時に致命的な問題に遭遇すると、 終了する前に、コンソールか - ErrorLog + ErrorLog のどちらかに問題を記述したメッセージを出力します。 最もよくあるエラーメッセージは - "Unable to bind to Port ..." - です。このメッセージは普通は次のどちらかが原因です:

    + 「Unable to bind to Port ...」 + です。このメッセージは普通は次のどちらかが原因です。

    より多くの問題解決の方策の説明は、 Apache FAQ をご覧下さい。

    - -

    ブート時の起動

    +

    ブート時の起動

    システムがリブートした後でも サーバが実行され続けるようにしたい場合は、 @@ -127,19 +87,15 @@ apachectl スクリプトは通常は、 init スクリプトとして直接リンクできるように設計されていますが、 念のためシステムの要求に合致していることを確認してください。

    - -

    追加情報

    +

    追加情報

    httpdapachectl 、サーバに含まれていたその他補助プログラムの、 コマンドラインオプションに関する追加情報は、 - サーバと補助プログラムページに + サーバと補助プログラムページに 記載されています。 Apache 配布に含まれている全モジュール、 それによって提供されるディレクティブ のドキュメントもあります。

    - - - - +

    Apache HTTP Server Version 2.0

    索引ホーム \ No newline at end of file diff --git a/docs/manual/mod/core.html.en b/docs/manual/mod/core.html.en index 40c3da6900..06b3cf818e 100644 --- a/docs/manual/mod/core.html.en +++ b/docs/manual/mod/core.html.en @@ -1897,7 +1897,7 @@ is accessed by an incompatible browser

    See also


    ServerTokens Directive

    Description: Configures the Server HTTP response header
    Syntax: - ServerTokens Minimal|ProductOnly|OS|Full
    Default: + ServerTokens Major|Minor|Minimal|ProductOnly|OS|Full
    Default: ServerTokens Full
    Context: server config
    Status: Core
    Module: @@ -1913,20 +1913,30 @@ is accessed by an incompatible browser
    Server sends (e.g.): 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 sends (e.g.): Server: - Apache/1.3.0
    + Apache/2.0.41
    ServerTokens OS
    -
    Server sends (e.g.): Server: Apache/1.3.0 +
    Server sends (e.g.): Server: Apache/2.0.41 (Unix)
    ServerTokens Full (or not specified)
    -
    Server sends (e.g.): Server: Apache/1.3.0 - (Unix) PHP/3.0 MyMod/1.2
    +
    Server sends (e.g.): Server: Apache/2.0.41 + (Unix) PHP/4.2.2 MyMod/1.2

    This setting applies to the entire server, and cannot be diff --git a/docs/manual/mpm.html.ja.jis b/docs/manual/mpm.html.ja.jis index 040c04a162..d90ec16a22 100644 --- a/docs/manual/mpm.html.ja.jis +++ b/docs/manual/mpm.html.ja.jis @@ -1,39 +1,27 @@ - - - - - - - - Apache Multi-Processing Modules (MPMs) - - - - - - - -

    Apache マルチプロセッシングモジュール

    - -

    Apache HTTP サーバは異なる幅広い環境、多種多様なプラットホームで +マルチプロセッシングモジュール (MPM) - Apache HTTP Server

    [APACHE DOCUMENTATION]

    Apache HTTP Server Version 2.0

    マルチプロセッシングモジュール (MPM)

    +

    この文書ではマルチプロセッシングモジュールがどのようなもので、 +Apache HTTP サーバでどのように使用されるかについて解説しています。

    +

    はじめに

    + +

    Apache HTTP サーバは異なる幅広い環境、多種多様なプラットホームで 動作するように、パワフルで柔軟性に富んだ設計になっています。 異なるプラットホーム・異なる環境ではしばしば、 異なる機能が必要になったり、 - 同じ機能でも効率のために異なる実装が必要になったりします。 + 同じ機能でも効率のために異なる実装が必要になったりします。 Apache ではモジュール化された設計により幅広い環境に適応してきました。 この設計のおかげで、管理者は コンパイル時または実行時にどのモジュールをロードするか選ぶことによって、 - どの機能をサーバに取り込むか選択することがができます。

    + どの機能をサーバに取り込むか選択することがができます。

    Apache 2.0 では、 このモジュール化された設計をサーバの基本機能にまで拡張しました。 - サーバには精選されたマルチプロセッシングモジュール (MPM) が - 付いてきて、 - これらはマシンのネットワークポートをバインドしたり、 - リクエストを受け付けたり、リクエストを扱うよう子プロセスに - 割り当てたり、 + サーバには精選されたマルチプロセッシングモジュール (MPM) + が付いてきて、これらはマシンのネットワークポートをバインドしたり、 + リクエストを受け付けたり、リクエストを扱うよう子プロセスに割り当てたり、 といった役割を持ちます。

    モジュール化された設計をサーバのこのレベルまで拡張することで @@ -43,7 +31,7 @@

  • Apache は幅広いオペレーティングシステムを より美しく効率的にサポートできます。 特に Windows 版の Apache は随分効率的になりました。 - なぜなら mpm_winnt + なぜなら mpm_winnt によって、Apache 1.3 で用いられていた POSIX レイヤの代わりにネイティブのネットワーク機能を 利用できるからです。 @@ -53,12 +41,12 @@
  • サーバは特定のサイト向けに、より上手にカスタマイズできます。 例えば、非常に大きなスケーラビリティを必要とするサイトでは、 - worker といったスレッド化された + worker といったスレッド化された MPM を利用できる一方で、安定性や古いソフトウェアとの互換性を - 必要とするサイトでは preforking MPM + 必要とするサイトでは prefork が利用できます。また、 異なるホストを異なるユーザ ID で動作させる - (perchild) といった + (perchild) といった 特別な機能も提供できます。
  • @@ -69,7 +57,7 @@ 利用可能な MPM は module インデックスにあります。

    -

    MPM を選ぶ

    +

    MPM を選ぶ

    MPM は設定中に選択して、サーバ内部にコンパイルされなければ なりません。 @@ -77,7 +65,7 @@ そもそもスレッドが使われているということを知る必要があります。 MPM には Unix 上でスレッドを用いるものや、スレッドをまったく 使わないものがあるので、 - Apache は、MPM が設定中に選択されて Apache 内部に組み込まれた場合の方が + Apache は、MPM が設定中に選択されて Apache 内部に組み込まれた場合の方が 常により良いパフォーマンスを発揮します。

    望みの MPM を実際に選ぶためには、./configure スクリプトで @@ -89,19 +77,16 @@ このコマンドは、MPM を含め、サーバにコンパイルで組み込まれたモジュール全てを 列挙します。

    - -

    MPM デフォルト値

    - -
      -
    • BeOS: beos
    • - -
    • OS/2: mpmt_os2
    • - -
    • Unix: prefork
    • - -
    • Windows: winnt
    • -
    - - - - +

    MPM デフォルト値

    + +

    次表に様々な OS 向けのデフォルトの MPM 一覧を掲載しています。 +コンパイル時に意図的に他を選択しなければ、自動的にこれらの MPM +が選択されます。

    + + + + + + +
    BeOSbeos
    OS/2mpmt_os2
    Unixprefork
    Windowsmpm_winnt
    +

    Apache HTTP Server Version 2.0

    索引ホーム \ No newline at end of file -- 2.40.0