Google Git
Sign in
apache / httpd / cced8282a86bf1b4d328e4322f601ea32a0db7b9 / . / 2.4.x / docs / manual / mod / mod_proxy_ajp.xml.ja
blob: 698975c2c9a892455b63c79b0298a2c6e9b3e55e [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.ja.xsl"?>
<!-- English Revision: 669473:1673563 (outdated) -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="mod_proxy_ajp.xml.meta">
<name>mod_proxy_ajp</name>
<description><module>mod_proxy</module> で AJP
をサポートするためのモジュール</description>
<status>Extension</status>
<sourcefile>mod_proxy_ajp.c</sourcefile>
<identifier>proxy_ajp_module</identifier>
<summary>
<p>本モジュールには <module>mod_proxy</module> が<em>必要です</em>。
<code>Apache JServ Protocol version 1.3</code> (以降 <em>AJP13</em>)
をサポートします。</p>
<p><code>AJP13</code> プロトコルを扱えるようにするには
<module>mod_proxy</module> と <module>mod_proxy_ajp</module>
をサーバに組み込む必要があります。</p>
<note type="warning"><title>警告</title>
<p><a href="#access"
>安全なサーバにする</a>までプロクシ機能は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
インターネット全体にとっても危険です。</p>
</note>
</summary>
<seealso><module>mod_proxy</module></seealso>
<section id="overviewprotocol"><title>プロトコルの概要</title>
<p><code>AJP13</code> プロトコルはパケット指向です。
可読なプレーンテキスト形式ではなくバイナリ形式になったのは、
おそらくパフォーマンス上の理由によります。
ウェブサーバはサーブレットコンテナと TCP コネクションで通信します。
ソケット生成は重い処理なので、負荷を減らすために、サーブレットコンテナとの
TCP 接続を維持し、複数のリクエスト・レスポンス処理サイクルに対して一つの
コネクションを使いまわすようになっています。</p>
<p>あるリクエストにコネクションが割り当てられると、その処理サイクルが
完了するまで他のものに使われることはありません。
つまりコネクション上では、リクエストの同時処理は行われません。
このため、コネクション両端での実行するコードを簡潔にできる一方で、
同時に開くコネクションは多くなっています。</p>
<p>サーブレットコンテナへのコネクションを開いた後は、コネクションの状態は
次のどれかになります:</p>
<ul>
<li> Idle <br />コネクション上で処理されているリクエストはありません。</li>
<li> Assigned <br />コネクションはリクエストを処理中です。</li>
</ul>
<p>コネクションが特定のリクエストにアサインされると、基本的な情報 (例えば
HTTP ヘッダ等) が圧縮された形 (例えば通常の文字列は整数にエンコードされます)
で転送されます。詳細は下記の「リクエストパケットの構造」を参照してください。
リクエストにボディが存在 <code>(content-length > 0)</code> すれば、
基本的な情報の直後に別パケットで転送されます。</p>
<p>この時点でおそらく、サーブレットコンテナは処理を開始できるようになります。
ですので、次のメッセージをウェブサーバに戻して知らせられるようになります。</p>
<ul>
<li>SEND_HEADERS <br/>ブラウザにヘッダを送信します。</li>
<li>SEND_BODY_CHUNK <br/>ブラウザにボディデータのチャンクを送ります。
</li>
<li>GET_BODY_CHUNK <br/>リクエストのデータを全て受け取り終わっていないときに、
残っているデータを受け取ります。パケットにある定まった最大長があり、任意の
大きさのデータがリクエストのボディとして含まれうる場合
(例えばファイルのアップロードの場合) に必要となります。
(注: HTTP のチャンク転送とは関連ありません。)</li>
<li>END_RESPONSE <br/>リクエスト処理サイクルを終了します。</li>
</ul>
<p>個々のメッセージはそれぞれ異なるデータパケット形式になっています。
後述の「レスポンスパケットの構造」を参照してください。</p>
</section>
<section id="basppacketstruct"><title>基本パケット構造</title>
<p>このプロトコルには XDR から受け継いだ部分が少しありますが、多くの点で
異なります (例えば 4 バイトアライメントでないことなど) 。</p>
<p>バイトオーダー: 個々のバイトのエンディアンがどうなっているかは、
私は詳しくないのですが、リトルエンディアンになっていると思います。
XDR 仕様でそうなっているのと、素晴らしいことに sys/socket ライブラリが
(C で) そういう風にできているのでそうなのだと思いました。
ソケット呼び出しの内部についてより詳しい方がいらっしゃいましたら、
ご教授ください。</p>
<p>プロトコルには 4 つのデータタイプがあります: byte, boolean,
integer, string です。</p>
<dl>
<dt><strong>Byte</strong></dt><dd>バイト一つです。</dd>
<dt><strong>Boolean</strong></dt>
<dd>バイト一つで、<code>1 = true</code>, <code>0 = false</code> です。
(C のように) 非零を真として扱ってしまうと、ある場合は動くかもしれませんし、
動かないかもしれません。</dd>
<dt><strong>Integer</strong></dt>
<dd><code>0 から 2^16 (32768)</code> の範囲の数字。高次の 2 バイトが
先に格納されます。</dd>
<dt><strong>String</strong></dt>
<dd>可変長の文字列 (2^16 が長さの上限) 。長さ情報のパケット 2 バイトの後に
文字列 (終端文字 '\0' を含む) が続く形式でエンコードされます。
エンコードされている長さ情報は最後の '\0' を<strong>カウントしない</strong>
ことに注意してください――これは <code>strlen</code> と同様です。
これらの終端文字をスキップするために、あまり意味の無いインクリメント文
をたくさん書かないといけないのは、
Java の側から見ると少し紛らわしく感じられるかもしれません。
こうなった理由はおそらく、Servlet コンテナから返される文字列を読み出す時に、
効率よく C のコードを書けるようにする――サーブレットから返される
文字列は \0 文字で終端されているので、C のコードではわざわざコピーをせずに、
一つのバッファへのリファレンスを取り回すように書くことができる――
ためだと思われます。
'\0' 文字がない場合は、C では文字列の規則に合うようにコピーしなければ
いけなくなってしまいます。</dd>
</dl>
<section><title>パケットサイズ</title>
<p>多くのコードでそうなっているのですが、パケットサイズの最大サイズは
<code>8 * 1024 (8K)</code> です。パケットの実際の長さはヘッダに
エンコードされて入っています。</p>
</section>
<section><title>パケットヘッダ</title>
<p>サーバからコンテナに送出されるパケットは <code>0x1234</code> で始まります。
コンテナからサーバに送られるパケットは <code>AB</code> (ASCII コード A と
ASCII コード B) で始まります。この二バイトの後に、ペイロード長が (上記の形式で)
続きます。このため、ペイロード長の最大値は 2^16 にできるように思えますが、
実際にはコードでは最大値は 8K に設定されています。</p>
<table>
<tr>
<td colspan="6"><em>パケット形式 (Server->Container)</em></td>
</tr>
<tr>
<td>Byte</td>
<td>0</td>
<td>1</td>
<td>2</td>
<td>3</td>
<td>4...(n+3)</td>
</tr>
<tr>
<td>Contents</td>
<td>0x12</td>
<td>0x34</td>
<td colspan="2">データ長 (n)</td>
<td>Data</td>
</tr>
</table>
<table>
<tr>
<td colspan="6"><em>パケット形式 (Container->Server)</em></td>
</tr>
<tr>
<td>Byte</td>
<td>0</td>
<td>1</td>
<td>2</td>
<td>3</td>
<td>4...(n+3)</td>
</tr>
<tr>
<td>Contents</td>
<td>A</td>
<td>B</td>
<td colspan="2">データ長 (n)</td>
<td>Data</td>
</tr>
</table>
<p>ほとんどのパケットで、ペイロードの最初のバイトがメッセージの型をエンコード
しています。例外はサーバからコンテナに送られるリクエストボディパケットです
――これらは標準的なパケット形式 (<code>0x1234</code> とパケット長)
ですが、その後に続くプレフィックスコードがありません。</p>
<p>ウェブサーバは次のメッセージをサーブレットコンテナに送出できます。</p>
<table>
<tr>
<td>コード</td>
<td>パケットの型</td>
<td>意味</td>
</tr>
<tr>
<td>2</td>
<td>Forward Request</td>
<td>リクエスト処理サイクルを後続のデータとともに開始する。</td>
</tr>
<tr>
<td>7</td>
<td>Shutdown</td>
<td>ウェブサーバがコンテナに、コンテナを終了するように伝える。</td>
</tr>
<tr>
<td>8</td>
<td>Ping</td>
<td>ウェブサーバがコンテナに制御を受け持つように伝える
(セキュアログインフェーズ) 。</td>
</tr>
<tr>
<td>10</td>
<td>CPing</td>
<td>ウェブサーバがコンテナに CPong で即座に応答するように伝える。</td>
</tr>
<tr>
<td>none</td>
<td>Data</td>
<td>サイズ (2 バイト) とそれに続くボディデータ。</td>
</tr>
</table>
<p>基本的なセキュリティを確保するため、ホストされているマシンと同一の
マシンからのリクエストに対してのみ、コンテナは実際に <code>Shutdown</code>
を実行します。</p>
<p>最初の <code>Data</code> パケットは、<code>Forward Request</code>
の直後にウェブサーバから送られます。</p>
<p>サーブレットコンテナはウェブサーバに、次のタイプのメッセージを送ることが
できます :</p>
<table>
<tr>
<td>コード</td>
<td>パケットの型</td>
<td>意味</td>
</tr>
<tr>
<td>3</td>
<td>Send Body Chunk</td>
<td>サーブレットコンテナからウェブサーバに
(そしておそらくそのままブラウザに)、ボディのチャンクを送る。</td>
</tr>
<tr>
<td>4</td>
<td>Send Headers</td>
<td>サーブレットコンテナからウェブサーバに (そしておそらくそのままブラウザに)
レスポンスヘッダを送る。</td>
</tr>
<tr>
<td>5</td>
<td>End Response</td>
<td>レスポンス (つまりリクエスト処理サイクル) 終了の目印を送る。
</td>
</tr>
<tr>
<td>6</td>
<td>Get Body Chunk</td>
<td>まだ全て転送されていない場合、残っているリクエストのデータを受け取る。
</td>
</tr>
<tr>
<td>9</td>
<td>CPong 応答</td>
<td>CPing リクエストに応答する。</td>
</tr>
</table>
<p>上記メッセージは、それぞれ内部構造が異なっています。詳細は下記をご覧ください。
</p>
</section>
</section>
<section id="rpacetstruct"><title>リクエストパケット構造</title>
<p>サーバからコンテナへ送られるメッセージが
<em>Forward Request</em> 型の場合 :</p>
<example><pre>
AJP13_FORWARD_REQUEST :=
prefix_code (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
method (byte)
protocol (string)
req_uri (string)
remote_addr (string)
remote_host (string)
server_name (string)
server_port (integer)
is_ssl (boolean)
num_headers (integer)
request_headers *(req_header_name req_header_value)
attributes *(attribut_name attribute_value)
request_terminator (byte) OxFF
</pre></example>
<p><code>request_headers</code> は次のような構造になっています :
</p><example><pre>
req_header_name :=
sc_req_header_name | (string) [see below for how this is parsed]
sc_req_header_name := 0xA0xx (integer)
req_header_value := (string)
</pre></example>
<p><code>属性</code> はオプションで、次のような構造をしています :</p>
<example><pre>
attribute_name := sc_a_name | (sc_a_req_attribute string)
attribute_value := (string)
</pre></example>
<p>もっとも重要なヘッダは <code>content-length</code> だということに
注意してください。コンテナは次のパケットを探すかどうかを、
それを見て決めるからです。</p>
<section><title>Forward Request 要素の詳細な説明
</title></section>
<section><title>Request prefix</title>
<p>リクエストについては全て、この値は 2 になります。他の Prefix コードの詳細は
上記をご覧ください。</p>
</section>
<section><title>Method</title>
<p>HTTP メソッドは 1 バイトにエンコードされます :</p>
<table>
<tr><td>Command Name</td><td>Code</td></tr>
<tr><td>OPTIONS</td><td>1</td></tr>
<tr><td>GET</td><td>2</td></tr>
<tr><td>HEAD</td><td>3</td></tr>
<tr><td>POST</td><td>4</td></tr>
<tr><td>PUT</td><td>5</td></tr>
<tr><td>DELETE</td><td>6</td></tr>
<tr><td>TRACE</td><td>7</td></tr>
<tr><td>PROPFIND</td><td>8</td></tr>
<tr><td>PROPPATCH</td><td>9</td></tr>
<tr><td>MKCOL</td><td>10</td></tr>
<tr><td>COPY</td><td>11</td></tr>
<tr><td>MOVE</td><td>12</td></tr>
<tr><td>LOCK</td><td>13</td></tr>
<tr><td>UNLOCK</td><td>14</td></tr>
<tr><td>ACL</td><td>15</td></tr>
<tr><td>REPORT</td><td>16</td></tr>
<tr><td>VERSION-CONTROL</td><td>17</td></tr>
<tr><td>CHECKIN</td><td>18</td></tr>
<tr><td>CHECKOUT</td><td>19</td></tr>
<tr><td>UNCHECKOUT</td><td>20</td></tr>
<tr><td>SEARCH</td><td>21</td></tr>
<tr><td>MKWORKSPACE</td><td>22</td></tr>
<tr><td>UPDATE</td><td>23</td></tr>
<tr><td>LABEL</td><td>24</td></tr>
<tr><td>MERGE</td><td>25</td></tr>
<tr><td>BASELINE_CONTROL</td><td>26</td></tr>
<tr><td>MKACTIVITY</td><td>27</td></tr>
</table>
<p>今後の ajp13 バージョンでは、この一覧にない、今後追加されるメソッドを
送るかもしれません。</p>
</section>
<section><title>protocol, req_uri, remote_addr, remote_host, server_name,
server_port, is_ssl</title>
<p>これらはまさに文字通りのものです。どれも必要で、リクエストの毎回につき
送られます。</p>
</section>
<section><title>Headers</title>
<p><code>request_headers</code> の構造は次のようなものです :
まずヘッダの数 <code>num_headers</code> がエンコードされます。
次にヘッダ名 <code>req_header_name</code> / 値 <code>req_header_value</code>
の組が続きます。効率のため、一般的なヘッダは整数でエンコードして転送します。
ヘッダ名が基本ヘッダの一覧に無い場合は、通常通り (文字列として、長さ
プレフィックス付きで) 転送されます。一般的なヘッダ
<code>sc_req_header_name</code> の一覧とそのコードは次の通りです
(どれも大文字小文字を区別します) :</p>
<table>
<tr><td>名前</td><td>コードの値</td><td>コード名</td></tr>
<tr><td>accept</td><td>0xA001</td><td>SC_REQ_ACCEPT</td></tr>
<tr><td>accept-charset</td><td>0xA002</td><td>SC_REQ_ACCEPT_CHARSET
</td></tr>
<tr><td>accept-encoding</td><td>0xA003</td><td>SC_REQ_ACCEPT_ENCODING
</td></tr>
<tr><td>accept-language</td><td>0xA004</td><td>SC_REQ_ACCEPT_LANGUAGE
</td></tr>
<tr><td>authorization</td><td>0xA005</td><td>SC_REQ_AUTHORIZATION</td>
</tr>
<tr><td>connection</td><td>0xA006</td><td>SC_REQ_CONNECTION</td></tr>
<tr><td>content-type</td><td>0xA007</td><td>SC_REQ_CONTENT_TYPE</td>
</tr>
<tr><td>content-length</td><td>0xA008</td><td>SC_REQ_CONTENT_LENGTH</td>
</tr>
<tr><td>cookie</td><td>0xA009</td><td>SC_REQ_COOKIE</td></tr>
<tr><td>cookie2</td><td>0xA00A</td><td>SC_REQ_COOKIE2</td></tr>
<tr><td>host</td><td>0xA00B</td><td>SC_REQ_HOST</td></tr>
<tr><td>pragma</td><td>0xA00C</td><td>SC_REQ_PRAGMA</td></tr>
<tr><td>referer</td><td>0xA00D</td><td>SC_REQ_REFERER</td></tr>
<tr><td>user-agent</td><td>0xA00E</td><td>SC_REQ_USER_AGENT</td></tr>
</table>
<p>これを読み込む Java のコードでは、最初の 2 バイト整数を取り込み、
目印になるバイト <code>'0xA0'</code> であれば、ヘッダ名の配列の
インデックスを使います。先頭バイトが <code>0xA0</code> でない場合は、
先頭 2 バイトは文字列長を表す整数であると解釈し、読み込みはじめます。</p>
<p>ヘッダ名の長さは <code>0x9999 (==0xA000 -1)</code> 以上にならないという
仮定の下に動いていて、少しあいまいですが合理的な挙動になっています。</p>
<note><title>注:</title>
<code>content-length</code> ヘッダはとても重要です。
存在していて非ゼロであれば、リクエストにはボディがある (例えば POST
リクエスト) と推測し、そのボディを取り込むために
直後のパケットを入力ストリームから読み込みはじめます。
</note>
</section>
<section><title>属性</title>
<p><code>?</code> プレフィックスで始まる属性 (例 <code>?context</code>)
は。省略可能です。それぞれ属性の型を示す 1 バイトのコードと、
値(文字列か整数)が続きます。
これらは順不同で送ることができます (C のコードは常に下の一覧順に
送るようですが) 。
オプションの属性のリストの最後には、特別な終了コードが送られます。
コードの一覧は : </p>
<table>
<tr><td>Information</td><td>Code Value</td><td>Type Of Value</td><td>Note</td></tr>
<tr><td>?context</td><td>0x01</td><td>-</td><td>未実装
</td></tr>
<tr><td>?servlet_path</td><td>0x02</td><td>-</td><td>未実装
</td></tr>
<tr><td>?remote_user</td><td>0x03</td><td>String</td><td></td></tr>
<tr><td>?auth_type</td><td>0x04</td><td>String</td><td></td></tr>
<tr><td>?query_string</td><td>0x05</td><td>String</td><td></td></tr>
<tr><td>?jvm_route</td><td>0x06</td><td>String</td><td></td></tr>
<tr><td>?ssl_cert</td><td>0x07</td><td>String</td><td></td></tr>
<tr><td>?ssl_cipher</td><td>0x08</td><td>String</td><td></td></tr>
<tr><td>?ssl_session</td><td>0x09</td><td>String</td><td></td></tr>
<tr><td>?req_attribute</td><td>0x0A</td><td>String</td><td>Name (the name of the
attribute follows)</td></tr>
<tr><td>?ssl_key_size</td><td>0x0B</td><td>Integer</td><td></td></tr>
<tr><td>are_done</td><td>0xFF</td><td>-</td><td>request_terminator</td></tr>
</table>
<p><code>context</code> と <code>servlet_path</code> は現在の C の
コードではセットされていません。また、ほとんどの Java のコードでも、
このフィールドで何が送られても無視されます (これらのコードの後に文字列が
送られると壊れるものもあります)。
これがバグなのか、単に未実装なのか、歴史的経緯で残っているコードなのか
分かりませんが、コネクションの両側ともで見当たりません。</p>
<p><code>remote_user</code> と <code>auth_type</code> はおそらく
HTTP レベルの認証を参照していて、リモートユーザのユーザ名と認証に使用した
タイプ (例 Basic, Digest) についてやり取りします。</p>
<p><code>query_string</code>, <code>ssl_cert</code>,
<code>ssl_cipher</code>, <code>ssl_session</code>
は HTTP と HTTPS の対応する部分を参照します。</p>
<p><code>jvm_route</code> はスティッキーセッションのサポート――
ロードバランスしている複数のサーバ中の特定の Tomcat インスタンスと、
ユーザのセッションとを紐付ける機能――に使われます。</p>
<p>この基本属性一覧に無いものについては、<code>req_attribute</code>
コード <code>0x0A</code> 経由で属性を何個でも送ることができます。
属性の名前と値の文字列の組を、それぞれこのコードの直後に送ります。
環境変数はこの方法で伝えられます。</p>
<p>最後に属性が全て送信された後に、属性の終端を示す <code>0xFF</code>
が送出されます。この信号は属性の一覧の終わりを示すと同時に、リクエスト
パケットの終端をも示しています。</p>
</section>
</section>
<section id="resppacketstruct"><title>レスポンスパケット構造</title>
<p>コンテナがサーバに送り返すことのできるメッセージ:</p>
<example><pre>
AJP13_SEND_BODY_CHUNK :=
prefix_code 3
chunk_length (integer)
chunk *(byte)
chunk_terminator (byte) Ox00
AJP13_SEND_HEADERS :=
prefix_code 4
http_status_code (integer)
http_status_msg (string)
num_headers (integer)
response_headers *(res_header_name header_value)
res_header_name :=
sc_res_header_name | (string) [see below for how this is parsed]
sc_res_header_name := 0xA0 (byte)
header_value := (string)
AJP13_END_RESPONSE :=
prefix_code 5
reuse (boolean)
AJP13_GET_BODY_CHUNK :=
prefix_code 6
requested_length (integer)
</pre></example>
<section><title>詳細 :</title></section>
<section><title>Send Body Chunk</title>
<p>チャンクは基本的にはバイナリデータで、ブラウザに直接送られます。</p>
</section>
<section><title>Send Headers</title>
<p>ステータスコードとメッセージが通常の HTTP の通信にはあります (例
<code>200</code> と <code>OK</code>)。レスポンスヘッダ名は、
リクエストヘッダ名と同様の方法でエンコードされます。
コードと文字列の判別方法の詳細に関しては、上記の header_encoding
を参照してください。
一般的なヘッダのコードは :</p>
<table>
<tr><td>名前</td><td>コードの値</td></tr>
<tr><td>Content-Type</td><td>0xA001</td></tr>
<tr><td>Content-Language</td><td>0xA002</td></tr>
<tr><td>Content-Length</td><td>0xA003</td></tr>
<tr><td>Date</td><td>0xA004</td></tr>
<tr><td>Last-Modified</td><td>0xA005</td></tr>
<tr><td>Location</td><td>0xA006</td></tr>
<tr><td>Set-Cookie</td><td>0xA007</td></tr>
<tr><td>Set-Cookie2</td><td>0xA008</td></tr>
<tr><td>Servlet-Engine</td><td>0xA009</td></tr>
<tr><td>Status</td><td>0xA00A</td></tr>
<tr><td>WWW-Authenticate</td><td>0xA00B</td></tr>
</table>
<p>コードかヘッダ文字列の直後には、ヘッダの値がエンコードされます。</p>
</section>
<section><title>End Response</title>
<p>リクエスト処理サイクルの終了を知らせます。<code>reuse</code> フラグが真
<code>(==1)</code> の場合、現在使用している TCP コネクションは次の新しい
リクエストに使えるようになります。<code>reuse</code> が偽 (C のコードでは
1 以外の全て) の場合は、コネクションを閉じることになります。</p>
</section>
<section><title>Get Body Chunk</title>
<p>(ボディのサイズが大きすぎて最初のパケットに収まらない場合や、
リクエストがチャンク転送された場合などには、) コンテナはリクエストからの
データ読み込み要求をします。サーバ側はそれに対して、最小
<code>request_length</code> 最大 <code>(8186 (8 Kbytes - 6))</code>
の範囲で、未転送で残っているリクエストボディの大きさのデータを
送り返します。<br />
ボディにそれ以上データが残っていない場合 (つまりサーブレットが
ボディの最後を超えて読み込もうとした場合) 、サーバは
ペイロード長 0 の<em>空パケット</em><code>(0x12,0x34,0x00,0x00)</code>
を送り返します。</p>
</section>
</section>
</modulesynopsis>