From: Yoshiki Hayashi <yoshiki@apache.org>
Date: Wed, 11 Sep 2002 08:33:53 +0000 (+0000)
Subject: New XML.
X-Git-Tag: 2.0.42~81
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=77991b76b3e9ef80c5ca387ddd2c8f2c087acd0e;p=apache

New XML.

Submitted by:	Hiroaki KAWAI <hawk@bcl.t.u-tokyo.ac.jp>


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@96756 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/dso.xml.ja b/docs/manual/dso.xml.ja
new file mode 100644
index 0000000000..3822283f5b
--- /dev/null
+++ b/docs/manual/dso.xml.ja
@@ -0,0 +1,275 @@
+<?xml version="1.0" encoding="iso-2022-jp" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
+<!-- English revision: 1.2 -->
+
+<manualpage>
+  <relativepath href="."/>
+
+  <title>動的共有オブジェクト (DSO) サポート</title>
+
+  <summary>
+    <p>Apache HTTP サーバはモジュール化されたプログラムで、
+    管理者がモジュールを選択することでサーバに組み込む機能を選ぶことができます。
+    モジュールはサーバがビルドされるときに <code>httpd</code> バイナリに
+    静的に組み込むことができます。もしくは、<code>httpd</code> バイナリとは
+    別に存在する動的共有オブジェクト (訳注: Dynamic Shared Object)
+    (DSO) としてコンパイルすることも
+    できます。DSO モジュールはサーバがビルドされるときにコンパイルしたり、
+    Apache 拡張ツール (<a href="programs/apxs.html">apxs</a>) を
+    使って後でコンパイルして追加したりできます。</p>
+
+    <p>この文書は DSO モジュールの使い方と、仕組みについて
+    説明します。</p>
+  </summary>
+
+
+<section id="implementation"><title>実装</title>
+
+<related>
+<modulelist>
+<module>mod_so</module>
+</modulelist>
+<directivelist>
+<directive module="mod_so">LoadModule</directive>
+</directivelist>
+</related>
+
+    <p>個々の Apache モジュールをロードするための DSO サポートは
+    <module>mod_so.c</module> というモジュールの機能に基づいています。
+    このモジュール は Apache のコアに静的に組み込まれている必要があります。
+    それは <module>core.c</module> 以外では DSO にできない唯一の
+    モジュールです。事実上、他のすべての Apache のモジュールは、
+    <a href="install.html">インストールの文書</a>で説明されているように、
+    <code>configure</code> の
+    <code>--enable-<em>module</em>=shared</code> オプションでそれぞれを
+    DSO ビルドにすることにより、DSO モジュールにすることができます。
+    <code>mod_foo.so</code> のような DSO にモジュールがコンパイルされれば、
+    <code>httpd.conf</code> ファイル中で <module>mod_so</module> の
+    <directive module="mod_so">LoadModule</directive>
+    ディレクティブを使うことでサーバの起動や再起動時にこのモジュールを
+    ロードするようにできます。</p>
+
+    <p>Apache モジュール用の (特にサードパーティモジュールの) DSO ファイルの
+    作成を簡単にするために、<a href="programs/apxs.html">apxs</a>
+    (<em>APache eXtenSion</em>) という新しいサポートプログラムがあります。
+    Apache のソースツリーの<em>外で</em> DSO モジュールをビルドするために
+    使うことができます。発想は単純です: Apache のインストール時の
+    <code>configure</code>、<code>make install</code> のときに Apache の
+    C ヘッダをインストールし、DSO ビルド用のプラットフォーム依存の
+    コンパイラとリンカのフラグを <code>apxs</code> プログラムに追加します。
+    これにより、ユーザが Apache の配布ソースツリーなしで、さらに
+    DSO サポートのためのプラットフォーム依存のコンパイラやリンカの
+    フラグをいじることなく Apache のモジュールのソースをコンパイル
+    できるようになります。</p>
+</section>
+
+<section id="usage"><title>使用法の概要</title>
+
+    <p>Apache 2.0 の DSO 機能の概略を知ることができるための、
+    短く簡潔な概要です:</p>
+
+    <ol>
+      <li>
+        <em>配布されている</em> Apache モジュール、仮に <code>mod_foo.c</code>
+        として、それを DSO <code>mod_foo.so</code> にビルド、インストール: 
+
+<example>
+$ ./configure --prefix=/path/to/install --enable-foo=shared<br />
+$ make install
+</example>
+      </li>
+
+      <li>
+        <em>サードパーティ</em> Apache モジュール、仮に <code>mod_foo.c</code>
+        として、それを DSO <code>mod_foo.so</code> にビルド、インストール:
+
+<example>
+$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared<br />
+$ make install
+</example>
+      </li>
+
+      <li>
+        共有モジュールの <em>後々のインストール</em> のために
+        Apache を設定:
+
+<example>
+$ ./configure --enable-so<br />
+$ make install
+</example>
+      </li>
+
+      <li>
+        <em>サードパーティ</em> Apache モジュール、仮に <code>mod_foo.c</code>
+        として、それを <a href="programs/apxs.html">apxs</a> を使って
+        Apache ソースツリーの<em>外で</em> DSO にビルド、インストール:
+
+<example>
+$ cd /path/to/3rdparty<br />
+$ apxs -c mod_foo.c<br />
+$ apxs -i -a -n foo mod_foo.la
+</example>
+      </li>
+    </ol>
+
+    <p>どの場合においても、共有モジュールをコンパイルした後で、
+    <code>httpd.conf</code> で 
+    <directive module="mod_so">LoadModule</directive>
+    ディレクティブを使って Apache がモジュールを使用するように
+    しなければなりません。</p>
+</section>
+
+<section id="background"><title>背景</title>
+
+    <p>最近の Unix 系の OS には <em>動的共有オブジェクト</em> (DSO)
+    の動的リンク/ロードという気のきいた機構が
+    存在します。これは、実行時にプログラムのアドレス空間に
+    ロードできるような特別な形式でプログラムをビルドすることを
+    可能にします。</p>
+
+    <p>このロードは二つの方法で行なうことができます: 実行プログラムが
+    起動されたときに <code>lod.so</code> というシステムプログラム
+    により自動的に行なわれる方法と、実行プログラム中から、システムコール
+    <code>dlopen()/dlsym()</code> による Unix ローダへの
+    プログラムシステムのインタフェースを使って手動で行なう方法とが
+    あります。</p>
+
+    <p>最初の方法では DSO は普通は<em>共有ライブラリ</em>や <em>DSO
+    ライブラリ</em> と呼ばれていて、DSO の名前は
+    <code>libfoo.so</code> や <code>libfoo.so.1.2</code> のようになっています。
+    これらはシステムディレクトリ (通常 <code>/usr/lib</code>) に存在し、
+    実行プログラムへのリンクはビルド時に <code>-lfoo</code> をリンカに
+    指定することで確立されます。これによりライブラリへの参照が実行プログラムの
+    ファイルに書き込まれて、起動時に Unix のローダが <code>/usr/lib</code> や、
+    リンカの <code>-R</code> のようなオプションによりハードコードされたパス、
+    環境変数 <code>LD_LIBRARY_PATH</code> により設定されたパス、の中から
+    <code>libfoo.so</code> の場所を見つけることができます。それから、
+    実行プログラム中の (まだ未解決の) シンボルを DSO にあるシンボルで
+    解決します。</p>
+
+    <p>普通は実行プログラム中のシンボルは DSO からは参照されません
+    (DSO は一般的なコードによる再利用可能なライブラリですので)。
+    ですから、さらなるシンボルの解決は必要ありません。
+    シンボルは Unix ローダにより完全な解決が行なわれますので、実行ファイル自身は
+    何もする必要がありません。(実際のところ、静的でない方法でリンクされている
+    すべての実行プログラムに組み込まれている開始用のコードの一部に
+    <code>ld.so</code> を起動するコードが含まれています)。よく使われる
+    ライブラリの動的ロードの利点は明らかです。ライブラリのコードは
+    システムライブラリに <code>libc.so</code> のようにして一度保存するだけでよく、
+    プログラムのために必要なディスクの領域を節約することができます。</p>
+
+    <p>二つめの方法では DSO は普通は<em>共有オブジェクト</em>や
+    <em>DSO ファイル</em>と呼ばれていて、任意の拡張子を付けることができます
+    (ただし、標準的な名前は <code>foo.so</code> です)。
+    これらのファイルは通常はプログラム専用のディレクトリに置かれ、
+    これらを使う実行プログラムへのリンクは自動的にはされません。
+    ですので、実行プログラムは <code>dlopen()</code> を使って
+    実行時に手動で DSO をプログラムのアドレス空間にロードする必要があります。
+    この時点では実行プログラムに対して DSO のシンボルの解決は行なわれません。
+    しかし、その代わりに Unix のローダが DSO の (まだ未解決の) シンボルを
+    実行プログラムによりエクスポートされたシンボルと既にロードされた
+    DSO ライブラリによりエクスポートされたシンボル (特に、どこにでもある
+    <code>libc.so</code> のすべてのシンボル) で自動的に解決します。
+    こうすることで、DSO は最初から静的にリンクされていたかのように、
+    実行プログラムのシンボルを知ることができます。</p>
+
+    <p>最後に、DSO の API を利点を生かすために、プログラムは
+    後でディスパッチテーブル<em>など</em>でシンボルを使うことができるように、
+    <code>dlsym()</code> を使っていくつかのシンボルを解決します。
+    すなわち: 実行プログラムは必要なすべてのシンボルを手動で解決しなければ
+    なりません。この機構の利点はプログラムのオプショナルな部分は
+    必要になるまでロードする必要がない (だからメモリも消費しない)
+    ことです。必要ならば、基本プログラムの機能を拡張するために
+    これらの部分を動的にロードすることができます。</p>
+
+    <p>この DSO 機構は簡単なように見えますが、少なくとも一つ難しい点が
+    あります: プログラムを拡張するために DSO を使っているときに、
+    DSO が実行プログラムからシンボルを解決する点です (二番目の方法)。
+    これはなぜでしょうか。それは、DSO のシンボルを実行プログラムの
+    シンボルから「逆解決」するというのはライブラリの設計
+    (ライブラリはそれを使用するプログラムのことは何も
+    知らない) に反していて、この機能はすべてのプラットフォームに
+    あるわけではなく、標準化もされていないからです。
+    実際には実行プログラムのグローバルなシンボルは再エクスポートされることは
+    あまりなく、DSO から使うことができません。リンカにグローバルシンボルすべてを
+    エクスポートするようにさせる方法を見つけることが、実行時にプログラムを
+    拡張するために DSO を使うときの一番の問題です。</p>
+
+    <p>共有ライブラリのアプローチが普通の方法です。DSO 機構はそのために
+    設計されたものですから。したがって、その方法はオペレーティングシステムが
+    提供するほとんどすべての種類のライブラリで使われています。
+    一方、プログラムの拡張のために共有オブジェクトを使用する、という方は
+    あまり使われていません。</p>
+
+    <p>1998 年の時点で、実行時に実際に機能拡張のために DSO 機構を使っている
+    ソフトウェアパッケージは少しだけでした: Perl 5 (XS 機構と DnaLoader モジュール
+    によるもの)、Netscape サーバ<em>など</em>です。Apache はすでに
+    モジュールの概念を使って機能拡張をしていて、内部的にディスパッチリストに
+    基づいた外部モジュールの Apache コア機能へのリンクを行なっていましたので、
+    バージョン 1.3 から、Apache も DSO 機構を使う仲間になりました。
+    Apache は実行時に DSO を使ってモジュールをロードするようにすでに
+    運命付けられていたのです。</p>
+</section>
+
+<section id="advantages"><title>利点と欠点</title>
+
+    <p>上記の DSO に基づいた機能は以下の利点があります:</p>
+
+    <ul>
+      <li>実際のサーバプロセスを組み立てるために、
+      ビルド時に <code>configure</code> のオプションを使う代わりに
+      実行時に <code>httpd.conf</code> の設定用コマンド
+      <directive module="mod_so">LoadModule</directive>
+      を使うことができますので、サーバパッケージの柔軟性が高まりました。
+      たとえば、一つの Apache のインストールから
+      違う構成のサーバ (標準版と SSL 版、最小構成と拡張版 [mod_perl, PHP3]
+      <em>など</em>) を実行することができます。</li>
+
+      <li>インストールの後であっても、サーバのパッケージをサードパーティ
+      モジュールで簡単に拡張できるようになりました。これは、Apache コア
+      パッケージと、PHP3, mod_perl, mod_fastcgi <em>など</em> の追加の
+      パッケージを作成できるので、少なくともベンダのパッケージ管理者にとって
+      大きな利点があります。</li>
+
+      <li>Apache モジュールの開発が簡単になります。
+      これは DSO/<code>apxs</code> の組み合わせにより、Apache ソースツリーの
+      外で作業でき、開発中のモジュールの新しいバージョンを
+      実行中の Apache サーバに組み込むために <code>apxs -i</code> と
+      <code>apachectl restart</code> を行なうだけで良くなるからです。</li>
+    </ul>
+
+    <p>DSO には以下の欠点があります:</p>
+
+    <ul>
+      <li>すべてのオペレーティングシステムがプログラムのアドレス空間に
+      コードを動的ロードすることをサポートしているわではないので、
+      プラットフォームによっては DSO 機構は使えません。</li>
+
+      <li>Unix のローダがシンボルの解決をする必要ができたので、
+      そのオーバヘッドによりサーバの起動時間が約 20% 遅くなっています。</li>
+
+      <li>位置非依存コード (PIC) (訳注 position independent code) は
+      相対アドレスのために複雑なアセンブラのトリックが必要なことがあり、
+      それは必ずしも絶対アドレスと同じくらいの速度がでるわけではありませんので、
+      プラットフォームによってはサーバの実行速度が約 5% 遅くなります。</li>
+
+      <li>DSO モジュールはすべてのプラットフォームで他の DSO に基づいた
+      ライブラリに対してリンクできる (<code>ld -lfoo</code>)
+      というわけではありませんので (たとえば、a.out のプラットフォームでは
+      この機能はありませんが、ELF のプラットフォームにはあります)、
+      すべての種類のモジュールに DSO 機構を使えるわけではありません。
+      言い換えると、DSO ファイルとしてコンパイルされたモジュールの
+      使えるシンボルは、
+      Apache のコアのシンボル、C ライブラリ (<code>libc</code>) と
+      Apache コアが使っている他のすべての静的なライブラリと動的ライブラリの
+      シンボル、PIC による静的なライブラリ (<code>libfoo.a</code>) の
+      シンボルのみに制限されます。その他のコードを使う方法は、
+      Apache コア自身がすでにそのコードへの参照があるようにするか、
+      <code>dlopen ()</code> を使ってコードを自分自身でロードするかの
+     どちらかしかありません。</li>
+    </ul>
+
+</section>
+
+</manualpage>
diff --git a/docs/manual/handler.xml.ja b/docs/manual/handler.xml.ja
new file mode 100644
index 0000000000..123a33b06a
--- /dev/null
+++ b/docs/manual/handler.xml.ja
@@ -0,0 +1,146 @@
+<?xml version="1.0" encoding="iso-2022-jp" ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
+<!-- English revision: 1.2 -->
+
+<manualpage>
+  <relativepath href="."/>
+
+  <title>Apache のハンドラの使用</title>
+
+  <summary>
+    <p>Apache のハンドラの使用に関して記述しています。</p>
+  </summary>
+
+  <section id="definition">
+    <title>ハンドラとは</title>
+    <related>
+      <modulelist>
+        <module>mod_actions</module>
+        <module>mod_asis</module>
+        <module>mod_cgi</module>
+        <module>mod_imap</module>
+        <module>mod_info</module>
+        <module>mod_mime</module>
+        <module>mod_negotiation</module>
+        <module>mod_status</module>
+     </modulelist>
+      <directivelist>
+        <directive module="mod_actions">Action</directive>
+        <directive module="mod_mime">AddHandler</directive>
+        <directive module="mod_mime">RemoveHandler</directive>
+        <directive module="mod_mime">SetHandler</directive>
+      </directivelist>
+    </related>
+    
+
+    <p>「ハンドラ」とは、ファイルが呼ばれたときに実行される動作の
+    Apache における内部表現です。
+    通常、ファイルはファイル型に基づいた暗黙のハンドラがあります。
+    普通はすべてのファイルは単にサーバに扱われますが、
+    ファイルタイプの中には別に「ハンドル」(訳注: 扱う)
+    されるものもあります。</p>
+
+    <p>Apache 1.1 では、ハンドラを明示的に使用する機能が追加されました。
+    ファイルの拡張子や置いている場所に基づいて、
+    ファイル型と関係なくハンドラを指定することができます。
+    これはより優雅な解決法という点と、ファイルにタイプ<strong>と</strong
+    >ハンドラの両方を関連付けることができるという点で優れています。
+    (<a href="mod/mod_mime.html#multipleext"
+    >複数の拡張子のあるファイル</a>も参照してください)。</p>
+
+    <p>ハンドラはサーバに組み込んだり、モジュールとして含めたり、
+    <directive module="mod_actions">Action</directive>
+    ディレクティブとして追加したりすることができます。
+    以下は標準配布に組み込まれているハンドラです。
+    </p>
+
+    <ul>
+      <li><strong>default-handler</strong>:<code>default_handelr()</code>
+      を使ってファイルを送ります。
+      静的なコンテンツを扱うときにデフォルトで使用されるハンドラです。
+      (<module>core</module>)</li>
+
+      <li><strong>send-as-is</strong>:
+      HTTP ヘッダのあるファイルをそのまま送ります。
+      (<module>mod_asis</module>)</li>
+
+      <li><strong>cgi-script</strong>: ファイルを CGI
+      スクリプトとして扱います。
+      (<module>mod_cgi</module>)</li>
+
+      <li><strong>imap-file</strong>:
+      イメージマップのルールファイルとして解析します。
+      (<module>mod_imap</module>)</li>
+
+      <li><strong>server-info</strong>: サーバの設定情報を取得します。
+      (<module>mod_info</module>)</li>
+
+      <li><strong>server-status</strong>: サーバの状態報告を取得します。
+      (<module>mod_status</module>)</li>
+
+      <li><strong>type-map</strong>:
+      コンテントネゴシエーションのためのタイプマップとして解析します。
+      (<module>mod_negotiation</module>)</li>
+    </ul>
+  </section>
+  <section id="examples">
+    <title>例</title>
+
+    <section id="example1">
+      <title>CGI スクリプトを用いて静的なコンテンツを変更する</title>
+
+      <p>以下のディレクティブによって、拡張子が <code>html</code>
+      であるファイルは <code>footer.pl</code>
+      CGI スクリプトを起動するようになります。</p>
+      
+      <example>
+        Action add-footer /cgi-bin/footer.pl<br/>
+        AddHandler add-footer .html
+      </example>
+
+      <p>CGI スクリプトは希望の修正や追加を行なって、元々要求された文書
+      (環境変数 <code>PATH_TRANSLATED</code>
+      で指されています) を送る責任があります。
+      </p>
+
+    </section>
+    <section id="example2">
+      <title>HTTP ヘッダのあるファイル</title>
+
+      <p>以下のディレクティブは <code>send-as-is</code>
+      ハンドラを使用するように指示します。このハンドラは自分自身の HTTP
+      ヘッダを持っているファイルに使用されます。ここでは、拡張子に関わらず、
+      <code>/web/htdocs/asis</code> ディレクトリにある全てのファイルは
+      <code>send-as-is</code> ハンドラによって扱われます。</p>
+
+      <example>
+        &lt;Directory /web/htdocs/asis&gt;<br/>
+        SetHandler send-as-is<br/>
+        &lt;/Directory&gt;
+      </example>
+      
+    </section>
+  </section>
+  <section id="programmer">
+    <title>プログラマ向けのメモ</title>
+
+    <p>ハンドラの機能を実装するために、利用すると便利かもしれないものが
+    <a href="developer/API.html">Apache API</a>
+    に追加されました。詳しく言うと、<code>request_rec</code>
+    構造体に新しいレコードが追加されたということです。</p>
+
+    <example>
+     char *handler
+    </example>
+
+    <p>もしモジュールがハンドラに関わりたい場合、
+    やらなければならないことは、リクエストが <code>invoke_handler</code>
+    ステージに達する以前に <code>r-&gt;handler</code>
+    を設定することだけです。ハンドラはコンテントタイプの代わりに
+    ハンドラ名を使うようになっていること以外は、以前と同じように実装されています。
+    必ず要求されているわけではありませんが、メディアタイプ
+    の名前空間を侵さないように、ハンドラの名前にはスラッシュを含まない、
+    ダッシュ (訳注: "-") で分離された名前を付ける習慣になっています。</p>
+  </section>
+</manualpage>
diff --git a/docs/manual/upgrading.xml.ja b/docs/manual/upgrading.xml.ja
new file mode 100644
index 0000000000..0812d019b7
--- /dev/null
+++ b/docs/manual/upgrading.xml.ja
@@ -0,0 +1,169 @@
+<?xml version='1.0' encoding='iso-2022-jp' ?>
+<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
+<?xml-stylesheet type="text/xsl" href="./style/manual.ja.xsl"?>
+<manualpage>
+<relativepath href="."/>
+<!-- English revision: 1.3 -->
+
+<title>1.3 から 2.0 へのアップグレード</title>
+
+<summary>
+  <p>アップグレードを簡単にするために、既存の Apache ユーザに
+  非常に重要な情報をこの文書にまとめています。これは短い
+  注意書きとして書かれています。より詳しい情報は
+  <a href="new_features_2_0.html">新機能</a>の文書や
+  <code>src/CHANGES</code> ファイルで見つけられると思います。</p>
+</summary>
+
+  <section id="compile-time">
+    <title>コンパイル時の設定の変更</title>
+
+    <ul>
+      <li>Apache は <a href="install.html">ビルド処理の設定</a>
+      に <code>autoconf</code> と <code>libtool</code> を使うようになりました。
+      このシステムは Apache 1.3 の APACI システムと似ていますが、
+      まったく同じというわけではありません。</li>
+
+      <li>通常のコンパイルするかどうかを選択できるモジュール群に加えて、
+      Apache 2.0 は
+      リクエスト処理の主な部分を <a href="mpm.html">マルチプロセッシング
+      モジュール</a> (MPM) に移動しました。</li>
+    </ul>
+  </section>
+
+  <section id="run-time">
+    <title>実行時の設定の変更</title>
+
+    <ul>
+      <li>Apache 1.3 の時にコアサーバにあった多くのディレクティブは
+      MPM に移動しました。サーバに Apache 1.3 とできるだけ同じ振る舞いを
+      させたい場合は、<module>prefork</module> MPM を
+      選んでください。他の MPM はプロセスの作成やリクエストの処理の
+      制御に異なったディレクティブを使います。</li>
+
+      <li>Proxy モジュール (<module>mod_proxy</module>) は
+      HTTP/1.1 に対応するために再構成されました。重要な変更としては、
+      プロキシのアクセス制御が &lt;Directory proxy:&gt; ブロックの
+      代わりに &lt;Proxy&gt; ブロックに置かれるようになった、というものが
+      あります。</li>
+
+      <li>モジュールの中には、PATH_INFO (本当のファイル名の後に続く
+      パス情報) の扱いが変わったものがあります。以前はハンドラとして
+      実装されていたものがフィルタとして実装されるようになったものは PATH_INFO
+      のあるリクエストを受け付けません。<a
+      href="mod/mod_include.html">INCLUDES</a> などのフィルタは
+      コアハンドラの上に実装されていますので、PATH_INFO 付きの
+      リクエストを拒否します。
+      <directive module="core">AcceptPathInfo</directive>
+      ディレクティブを使ってコアハンドラが PATH_INFO 付きのリクエストを
+      受け付けるようにでき、それによって SSI で PATH_INFO を使う
+      機能を復活させることができます。</li>
+
+      <li><directive module="mod_negotiation">CacheNegotiatedDocs</directive>
+      ディレクティブは <code>on</code> もしくは <code>off</code> という引数を
+      取るようになりました。既に存在している
+      <code>CacheNegotiatedDocs</code> は <code>CacheNegotiatedDocs on</code>
+      に置き換えてください。</li>
+
+      <li>
+        <directive module="core">ErrorDocument</directive>
+	ディレクティブはテキストメッセージを
+        示すために引数の最初に使われていた引用符を使わないようになりました。
+        代わりに、メッセージを二重引用符で囲むようになっています。
+        例えば、既存の
+
+        <example>
+          ErrorDocument 403 "Some Message
+        </example>
+        は
+
+        <example>
+          ErrorDocument 403 "Some Message"
+        </example>
+
+        に置き換える必要があります。
+        二番目の引数は、有効な URL やパス名でない限り
+        テキストメッセージとして扱われます。
+      </li>
+
+      <li><code>AccessConfig</code> ディレクティブと
+      <code>ResourceConfig</code> ディレクティブは削除されました。
+      これらのディレクティブは同等の機能を持つ
+      <directive module="core">Include</directive> で
+      置き換えることができます。設定ファイルに取り込む代わりに、
+      上のディレクティブのデフォルト値を使っていた場合は、
+      httpd.conf に <code>Include conf/access.conf</code> と
+      <code>Include conf/srm.conf</code> を追加する必要があるでしょう。
+      以前のディレクティブによる順番のように Apache が設定ファイルを
+      読み込むようにするためには、httpd.conf の最後に
+      <code>srm.conf</code>、<code>access.conf</code> の順にそれぞれ
+      <code>Include</code> ディレクティブを書いてください。</li>
+
+      <li><code>BindAddress</code> ディレクティブと <code>Port</code>
+      ディレクティブは削除されました。同等の機能はより柔軟な
+      <directive module="mpm_common">Listen</directive>
+      ディレクティブにより提供されています。</li>
+
+      <li><code>Port</code> ディレクティブは Apache-1.3 には自己参照 URL で
+      使われるポート番号を設定する、という使用法もありました。
+      これは Apache-2.0 では新しい
+      <directive module="core">ServerName</directive>
+      構文によって行ないます。一つのディレクティブでホスト名<em>と</em>
+      自己参照 URL の両方を設定できるように構文が変更されました。</li>
+
+      <li><code>ServerName</code> ディレクティブは削除されました。
+      リクエストを扱う方法は MPM の選択により決定されるようになりました。
+      現時点では inetd から起動されるように設計された MPM はありません。</li>
+
+      <li><code>AgentLog</code> ディレクティブ、
+      <code>RefererLog</code> ディレクティブ、
+      <code>RefererIgnore</code> ディレクティブを提供していた
+      mod_log_agent と mod_log_referer モジュールは削除されました。
+      Agent ログと refere ログは mod_log_config の
+      <directive module="mod_log_config">CustomLog</directive>
+      ディレクティブにより実現可能です。</li>
+
+      <li><code>AddModule</code> ディレクティブと <code>ClearModuleList</code>
+      ディレクティブは削除されました。これらのディレクティブは、
+      モジュールが正しい順番で呼ばれるようにするために使われていました。
+      Apache 2.0 の新 API はモジュールが明示的に順番を指定できるように
+      なっており、これらのディレクティブは必要なくなりました。</li>
+
+      <li><code>FancyIndexing</code> ディレクティブは削除されました。
+      同じ機能は <directive module="mod_autoindex">IndexOptions</directive>
+      ディレクティブの <code>FancyIndexing</code> オプションで
+      実現できます。</li>
+    </ul>
+  </section>
+
+  <section id="misc">
+    <title>その他の変更</title>
+
+    <ul>
+      <li>バーチャルホストの設定を出力するために使われていた
+      <code>httpd</code> のコマンドラインオプション <code>-S</code> は
+      <code>-t -D DUMP_VHOSTS</code> に置き換えられました。</li>
+
+      <li>Apache 1.3 で実験的なモジュールだった mod_auth_digest は
+      標準モジュールになりました。</li>
+
+      <li>Apache 1.3 で実験的なモジュールだった mod_mmap_static は
+      mod_file_cache で置き換えられました。</li>
+
+      <li>Apache の配布は独立した <code>src</code> ディレクトリが
+      なくなるように、完全に再構成されました。その代わりに、
+      ソースは主ディレクトリに論理的に配置されるようになり、
+      コンパイルされたサーバのインストールは別ディレクトリへ
+      行なうようになりました。</li>
+    </ul>
+  </section>
+
+  <section id="third-party">
+    <title>サードパーティモジュール</title>
+
+    <p>Apache 2.0 のサーバ API には多くの変更が加えられました。
+    Apache 1.3 用の既存のモジュールは Apache 2.0 では修正なしでは
+    動き<strong>ません</strong>。詳細は <a
+    href="developer/">開発者向け文書</a> にあります。</p>
+  </section>
+</manualpage>