From d64d93df57366006de3303ba5755b5435c687129 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Andr=C3=A9=20Malo?= Date: Sun, 21 Nov 2004 12:56:18 +0000 Subject: [PATCH] fix line endings and set svn:eol-style=native git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@106084 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/mod_proxy_ajp.xml.ja | 1048 ++++++++++----------- docs/manual/mod/mod_proxy_balancer.xml.ja | 98 +- 2 files changed, 573 insertions(+), 573 deletions(-) diff --git a/docs/manual/mod/mod_proxy_ajp.xml.ja b/docs/manual/mod/mod_proxy_ajp.xml.ja index 7c5881bf76..551698eb4d 100644 --- a/docs/manual/mod/mod_proxy_ajp.xml.ja +++ b/docs/manual/mod/mod_proxy_ajp.xml.ja @@ -1,524 +1,524 @@ - - - - - - - - - -mod_proxy_ajp -mod_proxy で AJP -をサポートするためのモジュール -Extension -proxy_ajp.c -proxy_ajp_module - - -

本モジュールには mod_proxy が必要です。 - Apache JServ Protocol version 1.3 (以降 AJP13) - をサポートします。

- -

AJP13 プロトコルを扱えるようにするには - mod_proxy と mod_proxy_ajp - をサーバに組み込む必要があります。

- - 警告 -

安全なサーバにするまでプロクシ機能は有効にしないでください。 - オープンプロキシサーバはあなた自身のネットワークにとっても、 - インターネット全体にとっても危険です。

- - - -mod_proxy - -
プロトコルの概要 -

AJP13 プロトコルはパケット指向です。 - 可読なプレーンテキスト形式ではなくバイナリ形式になったのは、 - おそらくパフォーマンス上の理由によります。 - ウェブサーバはサーブレットコンテナと TCP コネクションで通信します。 - ソケット生成は重い処理なので、負荷を減らすために、サーブレットコンテナとの - TCP 接続を維持し、複数のリクエスト・レスポンス処理サイクルに対して一つの - コネクションを使いまわすようになっています。

-

あるリクエストにコネクションが割り当てられると、その処理サイクルが - 完了するまで他のものに使われることはありません。 - つまりコネクション上では、リクエストの同時処理は行われません。 - このため、コネクション両端での実行するコードを簡潔にできる一方で、 - 同時に開くコネクションは多くなっています。

-

サーブレットコンテナへのコネクションを開いた後は、コネクションの状態は - 次のどれかになります:

-
    -
  • Idle
    コネクション上で処理されているリクエストはありません。
    • -
  • Assigned
    コネクションはリクエストを処理中です。
    • -
-

コネクションが特定のリクエストにアサインされると、基本的な情報 (例えば - HTTP ヘッダ等) が圧縮された形 (例えば通常の文字列は整数にエンコードされます) - で転送されます。詳細は下記の「リクエストパケットの構造」を参照してください。 - リクエストにボディが存在 (content-length > 0) すれば、 - 基本的な情報の直後に別パケットで転送されます。

-

この時点でおそらく、サーブレットコンテナは処理を開始できるようになります。 - ですので、次のメッセージをウェブサーバに戻して知らせられるようになります。

-
    -
  • SEND_HEADERS
    ブラウザにヘッダを送信します。
    • -
  • SEND_BODY_CHUNK
    ブラウザにボディデータのチャンクを送ります。 -
    • -
  • GET_BODY_CHUNK
    リクエストのデータを全て受け取り終わっていないときに、 - 残っているデータを受け取ります。パケットにある定まった最大長があり、任意の - 大きさのデータがリクエストのボディとして含まれうる場合 - (例えばファイルのアップロードの場合) に必要となります。 - (注: HTTP のチャンク転送とは関連ありません。)
    • -
  • END_RESPONSE
    リクエスト処理サイクルを終了します。
    • -
-

個々のメッセージはそれぞれ異なるデータパケット形式になっています。 - 後述の「レスポンスパケットの構造」を参照してください。

-
- -
基本パケット構造 -

このプロトコルには XDR から受け継いだ部分が少しありますが、多くの点で - 異なります (例えば 4 バイトアライメントでないことなど) 。

-

バイトオーダー: 個々のバイトのエンディアンがどうなっているかは、 - 私は詳しくないのですが、リトルエンディアンになっていると思います。 - XDR 仕様でそうなっているのと、素晴らしいことに sys/socket ライブラリが - (C で) そういう風にできているのでそうなのだと思いました。 - ソケット呼び出しの内部についてより詳しい方がいらっしゃいましたら、 - ご教授ください。

-

プロトコルには 4 つのデータタイプがあります: byte, boolean, - integer, string です。

-
-
Byte
バイト一つです。
-
Boolean
-
バイト一つで、1 = true, 0 = false です。 - (C のように) 非零を真として扱ってしまうと、ある場合は動くかもしれませんし、 - 動かないかもしれません。
-
Integer
-
0 から 2^16 (32768) の範囲の数字。高次の 2 バイトが - 先に格納されます。
-
String
-
可変長の文字列 (2^16 が長さの上限) 。長さ情報のパケット 2 バイトの後に - 文字列 (終端文字 '\0' を含む) が続く形式でエンコードされます。 - エンコードされている長さ情報は最後の '\0' をカウントしない - ことに注意してください――これは strlen と同様です。 - これらの終端文字をスキップするために、あまり意味の無いインクリメント文 - をたくさん書かないといけないのは、 - Java の側から見ると少し紛らわしく感じられるかもしれません。 - こうなった理由はおそらく、Servlet コンテナから返される文字列を読み出す時に、 - 効率よく C のコードを書けるようにする――サーブレットから返される - 文字列は \0 文字で終端されているので、C のコードではわざわざコピーをせずに、 - 一つのバッファへのリファレンスを取り回すように書くことができる―― - ためだと思われます。 - '\0' 文字がない場合は、C では文字列の規則に合うようにコピーしなければ - いけなくなってしまいます。
-
- -
パケットサイズ -

多くのコードでそうなっているのですが、パケットサイズの最大サイズは - 8 * 1024 (8K) です。パケットの実際の長さはヘッダに - エンコードされて入っています。

-
-
パケットヘッダ -

サーバからコンテナに送出されるパケットは 0x1234 で始まります。 - コンテナからサーバに送られるパケットは AB (ASCII コード A と - ASCII コード B) で始まります。この二バイトの後に、ペイロード長が (上記の形式で) - 続きます。このため、ペイロード長の最大値は 2^16 にできるように思えますが、 - 実際にはコードでは最大値は 8K に設定されています。

- - - - - - - - - - - - - - - - - - - -
パケット形式 (Server->Container)
Byte01234...(n+3)
Contents0x120x34データ長 (n)Data
- - - - - - - - - - - - - - - - - - - -
パケット形式 (Container->Server)
Byte01234...(n+3)
ContentsABデータ長 (n)Data
-

ほとんどのパケットで、ペイロードの最初のバイトがメッセージの型をエンコード - しています。例外はサーバからコンテナに送られるリクエストボディパケットです - ――これらは標準的なパケット形式 (0x1234 とパケット長) - ですが、その後に続くプレフィックスコードがありません。

-

ウェブサーバは次のメッセージをサーブレットコンテナに送出できます。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
コードパケットの型意味
2Forward Requestリクエスト処理サイクルを後続のデータとともに開始する。
7Shutdownウェブサーバがコンテナに、コンテナを終了するように伝える。
8Pingウェブサーバがコンテナに制御を受け持つように伝える - (セキュアログインフェーズ) 。
10CPingウェブサーバがコンテナに CPong で即座に応答するように伝える。
noneDataサイズ (2 バイト) とそれに続くボディデータ。
-

基本的なセキュリティを確保するため、ホストされているマシンと同一の - マシンからのリクエストに対してのみ、コンテナは実際に Shutdown - を実行します。

-

最初の Data パケットは、Forward Request - の直後にウェブサーバから送られます。

-

サーブレットコンテナはウェブサーバに、次のタイプのメッセージを送ることが - できます :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
コードパケットの型意味
3Send Body Chunkサーブレットコンテナからウェブサーバに - (そしておそらくそのままブラウザに)、ボディのチャンクを送る。
4Send Headersサーブレットコンテナからウェブサーバに (そしておそらくそのままブラウザに) - レスポンスヘッダを送る。
5End Responseレスポンス (つまりリクエスト処理サイクル) 終了の目印を送る。 -
6Get Body Chunkまだ全て転送されていない場合、残っているリクエストのデータを受け取る。 -
9CPong 応答CPing リクエストに応答する。
-

上記メッセージは、それぞれ内部構造が異なっています。詳細は下記をご覧ください。 -

-
-
-
リクエストパケット構造 -

サーバからコンテナへ送られるメッセージが - Forward Request 型の場合 :

- 
-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
-
-

request_headers は次のような構造になっています : - 

-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)
-
 -

属性 はオプションで、次のような構造をしています :

- 
-attribute_name := sc_a_name | (sc_a_req_attribute string)
-
-attribute_value := (string)
-
-
-

もっとも重要なヘッダは content-length だということに - 注意してください。コンテナは次のパケットを探すかどうかを、 - それを見て決めるからです。

-
Forward Request 要素の詳細な説明 -
-
Request prefix -

リクエストについては全て、この値は 2 になります。他の Prefix コードの詳細は - 上記をご覧ください。

-
-
Method -

HTTP メソッドは 1 バイトにエンコードされます :

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Command NameCode
OPTIONS1
GET2
HEAD3
POST4
PUT5
DELETE6
TRACE7
PROPFIND8
PROPPATCH9
MKCOL10
COPY11
MOVE12
LOCK13
UNLOCK14
ACL15
REPORT16
VERSION-CONTROL17
CHECKIN18
CHECKOUT19
UNCHECKOUT20
SEARCH21
MKWORKSPACE22
UPDATE23
LABEL24
MERGE25
BASELINE_CONTROL26
MKACTIVITY27
-

今後の ajp13 バージョンでは、この一覧にない、今後追加されるメソッドを - 送るかもしれません。

-
-
protocol, req_uri, remote_addr, remote_host, server_name, - server_port, is_ssl -

これらはまさに文字通りのものです。どれも必要で、リクエストの毎回につき - 送られます。

-
-
Headers -

request_headers の構造は次のようなものです : - まずヘッダの数 num_headers がエンコードされます。 - 次にヘッダ名 req_header_name / 値 req_header_value - の組が続きます。効率のため、一般的なヘッダは整数でエンコードして転送します。 - ヘッダ名が基本ヘッダの一覧に無い場合は、通常通り (文字列として、長さ - プレフィックス付きで) 転送されます。一般的なヘッダ - sc_req_header_name の一覧とそのコードは次の通りです - (どれも大文字小文字を区別します) :

- - - - - - - - - - - - - - - - - - - -
名前コードの値コード名
accept0xA001SC_REQ_ACCEPT
accept-charset0xA002SC_REQ_ACCEPT_CHARSET -
accept-encoding0xA003SC_REQ_ACCEPT_ENCODING -
accept-language0xA004SC_REQ_ACCEPT_LANGUAGE -
authorization0xA005SC_REQ_AUTHORIZATION
connection0xA006SC_REQ_CONNECTION
content-type0xA007SC_REQ_CONTENT_TYPE
content-length0xA008SC_REQ_CONTENT_LENGTH
cookie0xA009SC_REQ_COOKIE
cookie20xA00ASC_REQ_COOKIE2
host0xA00BSC_REQ_HOST
pragma0xA00CSC_REQ_PRAGMA
referer0xA00DSC_REQ_REFERER
user-agent0xA00ESC_REQ_USER_AGENT
-

これを読み込む Java のコードでは、最初の 2 バイト整数を取り込み、 - 目印になるバイト '0xA0' であれば、ヘッダ名の配列の - インデックスを使います。先頭バイトが 0xA0 でない場合は、 - 先頭 2 バイトは文字列長を表す整数であると解釈し、読み込みはじめます。

-

ヘッダ名の長さは 0x9999 (==0xA000 -1) 以上にならないという - 仮定の下に動いていて、少しあいまいですが合理的な挙動になっています。

- 注: - content-length ヘッダはとても重要です。 - 存在していて非ゼロであれば、リクエストにはボディがある (例えば POST - リクエスト) と推測し、そのボディを取り込むために - 直後のパケットを入力ストリームから読み込みはじめます。 - -
-
属性 -

? プレフィックスで始まる属性 (例 ?context) - は。省略可能です。それぞれ属性の型を示す 1 バイトのコードと、 - 値の文字列が続きます。 - これらは順不同で送ることができます (C のコードは常に下の一覧順に - 送るようですが) 。 - オプションの属性のリストの最後には、特別な終了コードが送られます。 - コードの一覧は :

- - - - - - - - - - - - - - -
InformationCode ValueNote
?context0x01未実装 -
?servlet_path0x02未実装 -
?remote_user0x03
?auth_type0x04
?query_string0x05
?jvm_route0x06
?ssl_cert0x07
?ssl_cipher0x08
?ssl_session0x09
?req_attribute0x0AName (the name of the - attribute follows)
?ssl_key_size0x0B
are_done0xFFrequest_terminator
-

context と servlet_path は現在の C の - コードではセットされていません。また、ほとんどの Java のコードでも、 - このフィールドで何が送られても無視されます (これらのコードの後に文字列が - 送られると壊れるものもあります)。 - これがバグなのか、単に未実装なのか、歴史的経緯で残っているコードなのか - 分かりませんが、コネクションの両側ともで見当たりません。

-

remote_user と auth_type はおそらく - HTTP レベルの認証を参照していて、リモートユーザのユーザ名と認証に使用した - タイプ (例 Basic, Digest) についてやり取りします。

-

query_string, ssl_cert, - ssl_cipher, ssl_session - は HTTP と HTTPS の対応する部分を参照します。

-

jvm_route はスティッキーセッションのサポート―― - ロードバランスしている複数のサーバ中の特定の Tomcat インスタンスと、 - ユーザのセッションとを紐付ける機能――に使われます。

-

この基本属性一覧に無いものについては、req_attribute - コード 0x0A 経由で属性を何個でも送ることができます。 - 属性の名前と値の文字列の組を、それぞれこのコードの直後に送ります。 - 環境変数はこの方法で伝えられます。

-

最後に属性が全て送信された後に、属性の終端を示す 0xFF - が送出されます。この信号は属性の一覧の終わりを示すと同時に、リクエスト - パケットの終端をも示しています。

-
-
- -
レスポンスパケット構造 -

コンテナがサーバに送り返すことのできるメッセージ:

- 
-AJP13_SEND_BODY_CHUNK :=
-  prefix_code   3
-  chunk_length  (integer)
-  chunk        *(byte)
-
-
-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)
-
-
詳細 :
-
Send Body Chunk -

チャンクは基本的にはバイナリデータで、ブラウザに直接送られます。

-
-
Send Headers -

ステータスコードとメッセージが通常の HTTP の通信にはあります (例 - 200 と OK)。レスポンスヘッダ名は、 - リクエストヘッダ名と同様の方法でエンコードされます。 - コードと文字列の判別方法の詳細に関しては、上記の header_encoding - を参照してください。 - 一般的なヘッダのコードは :

- - - - - - - - - - - - - -
名前コードの値
Content-Type0xA001
Content-Language0xA002
Content-Length0xA003
Date0xA004
Last-Modified0xA005
Location0xA006
Set-Cookie0xA007
Set-Cookie20xA008
Servlet-Engine0xA009
Status0xA00A
WWW-Authenticate0xA00B
-

コードかヘッダ文字列の直後には、ヘッダの値がエンコードされます。

-
-
End Response -

リクエスト処理サイクルの終了を知らせます。reuse フラグが真 - (==1) の場合、現在使用している TCP コネクションは次の新しい - リクエストに使えるようになります。reuse が偽 (C のコードでは - 1 以外の全て) の場合は、コネクションを閉じることになります。

-
-
Get Body Chunk -

(ボディのサイズが大きすぎて最初のパケットに収まらない場合や、 - リクエストがチャンク転送された場合などには、) コンテナはリクエストからの - データ読み込み要求をします。サーバ側はそれに対して、最小 - request_length 最大 (8186 (8 Kbytes - 6)) - の範囲で、未転送で残っているリクエストボディの大きさのデータを - 送り返します。
- ボディにそれ以上データが残っていない場合 (つまりサーブレットが - ボディの最後を超えて読み込もうとした場合) 、サーバは - ペイロード長 0 の空パケット(0x12,0x34,0x00,0x00) - を送り返します。

-
-
- - - + + + + + + + + + +mod_proxy_ajp +mod_proxy で AJP +をサポートするためのモジュール +Extension +proxy_ajp.c +proxy_ajp_module + + +

本モジュールには mod_proxy が必要です。 + Apache JServ Protocol version 1.3 (以降 AJP13) + をサポートします。

+ +

AJP13 プロトコルを扱えるようにするには + mod_proxy と mod_proxy_ajp + をサーバに組み込む必要があります。

+ + 警告 +

安全なサーバにするまでプロクシ機能は有効にしないでください。 + オープンプロキシサーバはあなた自身のネットワークにとっても、 + インターネット全体にとっても危険です。

+ + + +mod_proxy + +
プロトコルの概要 +

AJP13 プロトコルはパケット指向です。 + 可読なプレーンテキスト形式ではなくバイナリ形式になったのは、 + おそらくパフォーマンス上の理由によります。 + ウェブサーバはサーブレットコンテナと TCP コネクションで通信します。 + ソケット生成は重い処理なので、負荷を減らすために、サーブレットコンテナとの + TCP 接続を維持し、複数のリクエスト・レスポンス処理サイクルに対して一つの + コネクションを使いまわすようになっています。

+

あるリクエストにコネクションが割り当てられると、その処理サイクルが + 完了するまで他のものに使われることはありません。 + つまりコネクション上では、リクエストの同時処理は行われません。 + このため、コネクション両端での実行するコードを簡潔にできる一方で、 + 同時に開くコネクションは多くなっています。

+

サーブレットコンテナへのコネクションを開いた後は、コネクションの状態は + 次のどれかになります:

+
    +
  • Idle
    コネクション上で処理されているリクエストはありません。
    • +
  • Assigned
    コネクションはリクエストを処理中です。
    • +
+

コネクションが特定のリクエストにアサインされると、基本的な情報 (例えば + HTTP ヘッダ等) が圧縮された形 (例えば通常の文字列は整数にエンコードされます) + で転送されます。詳細は下記の「リクエストパケットの構造」を参照してください。 + リクエストにボディが存在 (content-length > 0) すれば、 + 基本的な情報の直後に別パケットで転送されます。

+

この時点でおそらく、サーブレットコンテナは処理を開始できるようになります。 + ですので、次のメッセージをウェブサーバに戻して知らせられるようになります。

+
    +
  • SEND_HEADERS
    ブラウザにヘッダを送信します。
    • +
  • SEND_BODY_CHUNK
    ブラウザにボディデータのチャンクを送ります。 +
    • +
  • GET_BODY_CHUNK
    リクエストのデータを全て受け取り終わっていないときに、 + 残っているデータを受け取ります。パケットにある定まった最大長があり、任意の + 大きさのデータがリクエストのボディとして含まれうる場合 + (例えばファイルのアップロードの場合) に必要となります。 + (注: HTTP のチャンク転送とは関連ありません。)
    • +
  • END_RESPONSE
    リクエスト処理サイクルを終了します。
    • +
+

個々のメッセージはそれぞれ異なるデータパケット形式になっています。 + 後述の「レスポンスパケットの構造」を参照してください。

+
+ +
基本パケット構造 +

このプロトコルには XDR から受け継いだ部分が少しありますが、多くの点で + 異なります (例えば 4 バイトアライメントでないことなど) 。

+

バイトオーダー: 個々のバイトのエンディアンがどうなっているかは、 + 私は詳しくないのですが、リトルエンディアンになっていると思います。 + XDR 仕様でそうなっているのと、素晴らしいことに sys/socket ライブラリが + (C で) そういう風にできているのでそうなのだと思いました。 + ソケット呼び出しの内部についてより詳しい方がいらっしゃいましたら、 + ご教授ください。

+

プロトコルには 4 つのデータタイプがあります: byte, boolean, + integer, string です。

+
+
Byte
バイト一つです。
+
Boolean
+
バイト一つで、1 = true, 0 = false です。 + (C のように) 非零を真として扱ってしまうと、ある場合は動くかもしれませんし、 + 動かないかもしれません。
+
Integer
+
0 から 2^16 (32768) の範囲の数字。高次の 2 バイトが + 先に格納されます。
+
String
+
可変長の文字列 (2^16 が長さの上限) 。長さ情報のパケット 2 バイトの後に + 文字列 (終端文字 '\0' を含む) が続く形式でエンコードされます。 + エンコードされている長さ情報は最後の '\0' をカウントしない + ことに注意してください――これは strlen と同様です。 + これらの終端文字をスキップするために、あまり意味の無いインクリメント文 + をたくさん書かないといけないのは、 + Java の側から見ると少し紛らわしく感じられるかもしれません。 + こうなった理由はおそらく、Servlet コンテナから返される文字列を読み出す時に、 + 効率よく C のコードを書けるようにする――サーブレットから返される + 文字列は \0 文字で終端されているので、C のコードではわざわざコピーをせずに、 + 一つのバッファへのリファレンスを取り回すように書くことができる―― + ためだと思われます。 + '\0' 文字がない場合は、C では文字列の規則に合うようにコピーしなければ + いけなくなってしまいます。
+
+ +
パケットサイズ +

多くのコードでそうなっているのですが、パケットサイズの最大サイズは + 8 * 1024 (8K) です。パケットの実際の長さはヘッダに + エンコードされて入っています。

+
+
パケットヘッダ +

サーバからコンテナに送出されるパケットは 0x1234 で始まります。 + コンテナからサーバに送られるパケットは AB (ASCII コード A と + ASCII コード B) で始まります。この二バイトの後に、ペイロード長が (上記の形式で) + 続きます。このため、ペイロード長の最大値は 2^16 にできるように思えますが、 + 実際にはコードでは最大値は 8K に設定されています。

+ + + + + + + + + + + + + + + + + + + +
パケット形式 (Server->Container)
Byte01234...(n+3)
Contents0x120x34データ長 (n)Data
+ + + + + + + + + + + + + + + + + + + +
パケット形式 (Container->Server)
Byte01234...(n+3)
ContentsABデータ長 (n)Data
+

ほとんどのパケットで、ペイロードの最初のバイトがメッセージの型をエンコード + しています。例外はサーバからコンテナに送られるリクエストボディパケットです + ――これらは標準的なパケット形式 (0x1234 とパケット長) + ですが、その後に続くプレフィックスコードがありません。

+

ウェブサーバは次のメッセージをサーブレットコンテナに送出できます。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
コードパケットの型意味
2Forward Requestリクエスト処理サイクルを後続のデータとともに開始する。
7Shutdownウェブサーバがコンテナに、コンテナを終了するように伝える。
8Pingウェブサーバがコンテナに制御を受け持つように伝える + (セキュアログインフェーズ) 。
10CPingウェブサーバがコンテナに CPong で即座に応答するように伝える。
noneDataサイズ (2 バイト) とそれに続くボディデータ。
+

基本的なセキュリティを確保するため、ホストされているマシンと同一の + マシンからのリクエストに対してのみ、コンテナは実際に Shutdown + を実行します。

+

最初の Data パケットは、Forward Request + の直後にウェブサーバから送られます。

+

サーブレットコンテナはウェブサーバに、次のタイプのメッセージを送ることが + できます :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
コードパケットの型意味
3Send Body Chunkサーブレットコンテナからウェブサーバに + (そしておそらくそのままブラウザに)、ボディのチャンクを送る。
4Send Headersサーブレットコンテナからウェブサーバに (そしておそらくそのままブラウザに) + レスポンスヘッダを送る。
5End Responseレスポンス (つまりリクエスト処理サイクル) 終了の目印を送る。 +
6Get Body Chunkまだ全て転送されていない場合、残っているリクエストのデータを受け取る。 +
9CPong 応答CPing リクエストに応答する。
+

上記メッセージは、それぞれ内部構造が異なっています。詳細は下記をご覧ください。 +

+
+
+
リクエストパケット構造 +

サーバからコンテナへ送られるメッセージが + Forward Request 型の場合 :

+ 
+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
+
+

request_headers は次のような構造になっています : + 

+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)
+
 +

属性 はオプションで、次のような構造をしています :

+ 
+attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+
+
+

もっとも重要なヘッダは content-length だということに + 注意してください。コンテナは次のパケットを探すかどうかを、 + それを見て決めるからです。

+
Forward Request 要素の詳細な説明 +
+
Request prefix +

リクエストについては全て、この値は 2 になります。他の Prefix コードの詳細は + 上記をご覧ください。

+
+
Method +

HTTP メソッドは 1 バイトにエンコードされます :

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Command NameCode
OPTIONS1
GET2
HEAD3
POST4
PUT5
DELETE6
TRACE7
PROPFIND8
PROPPATCH9
MKCOL10
COPY11
MOVE12
LOCK13
UNLOCK14
ACL15
REPORT16
VERSION-CONTROL17
CHECKIN18
CHECKOUT19
UNCHECKOUT20
SEARCH21
MKWORKSPACE22
UPDATE23
LABEL24
MERGE25
BASELINE_CONTROL26
MKACTIVITY27
+

今後の ajp13 バージョンでは、この一覧にない、今後追加されるメソッドを + 送るかもしれません。

+
+
protocol, req_uri, remote_addr, remote_host, server_name, + server_port, is_ssl +

これらはまさに文字通りのものです。どれも必要で、リクエストの毎回につき + 送られます。

+
+
Headers +

request_headers の構造は次のようなものです : + まずヘッダの数 num_headers がエンコードされます。 + 次にヘッダ名 req_header_name / 値 req_header_value + の組が続きます。効率のため、一般的なヘッダは整数でエンコードして転送します。 + ヘッダ名が基本ヘッダの一覧に無い場合は、通常通り (文字列として、長さ + プレフィックス付きで) 転送されます。一般的なヘッダ + sc_req_header_name の一覧とそのコードは次の通りです + (どれも大文字小文字を区別します) :

+ + + + + + + + + + + + + + + + + + + +
名前コードの値コード名
accept0xA001SC_REQ_ACCEPT
accept-charset0xA002SC_REQ_ACCEPT_CHARSET +
accept-encoding0xA003SC_REQ_ACCEPT_ENCODING +
accept-language0xA004SC_REQ_ACCEPT_LANGUAGE +
authorization0xA005SC_REQ_AUTHORIZATION
connection0xA006SC_REQ_CONNECTION
content-type0xA007SC_REQ_CONTENT_TYPE
content-length0xA008SC_REQ_CONTENT_LENGTH
cookie0xA009SC_REQ_COOKIE
cookie20xA00ASC_REQ_COOKIE2
host0xA00BSC_REQ_HOST
pragma0xA00CSC_REQ_PRAGMA
referer0xA00DSC_REQ_REFERER
user-agent0xA00ESC_REQ_USER_AGENT
+

これを読み込む Java のコードでは、最初の 2 バイト整数を取り込み、 + 目印になるバイト '0xA0' であれば、ヘッダ名の配列の + インデックスを使います。先頭バイトが 0xA0 でない場合は、 + 先頭 2 バイトは文字列長を表す整数であると解釈し、読み込みはじめます。

+

ヘッダ名の長さは 0x9999 (==0xA000 -1) 以上にならないという + 仮定の下に動いていて、少しあいまいですが合理的な挙動になっています。

+ 注: + content-length ヘッダはとても重要です。 + 存在していて非ゼロであれば、リクエストにはボディがある (例えば POST + リクエスト) と推測し、そのボディを取り込むために + 直後のパケットを入力ストリームから読み込みはじめます。 + +
+
属性 +

? プレフィックスで始まる属性 (例 ?context) + は。省略可能です。それぞれ属性の型を示す 1 バイトのコードと、 + 値の文字列が続きます。 + これらは順不同で送ることができます (C のコードは常に下の一覧順に + 送るようですが) 。 + オプションの属性のリストの最後には、特別な終了コードが送られます。 + コードの一覧は :

+ + + + + + + + + + + + + + +
InformationCode ValueNote
?context0x01未実装 +
?servlet_path0x02未実装 +
?remote_user0x03
?auth_type0x04
?query_string0x05
?jvm_route0x06
?ssl_cert0x07
?ssl_cipher0x08
?ssl_session0x09
?req_attribute0x0AName (the name of the + attribute follows)
?ssl_key_size0x0B
are_done0xFFrequest_terminator
+

context と servlet_path は現在の C の + コードではセットされていません。また、ほとんどの Java のコードでも、 + このフィールドで何が送られても無視されます (これらのコードの後に文字列が + 送られると壊れるものもあります)。 + これがバグなのか、単に未実装なのか、歴史的経緯で残っているコードなのか + 分かりませんが、コネクションの両側ともで見当たりません。

+

remote_user と auth_type はおそらく + HTTP レベルの認証を参照していて、リモートユーザのユーザ名と認証に使用した + タイプ (例 Basic, Digest) についてやり取りします。

+

query_string, ssl_cert, + ssl_cipher, ssl_session + は HTTP と HTTPS の対応する部分を参照します。

+

jvm_route はスティッキーセッションのサポート―― + ロードバランスしている複数のサーバ中の特定の Tomcat インスタンスと、 + ユーザのセッションとを紐付ける機能――に使われます。

+

この基本属性一覧に無いものについては、req_attribute + コード 0x0A 経由で属性を何個でも送ることができます。 + 属性の名前と値の文字列の組を、それぞれこのコードの直後に送ります。 + 環境変数はこの方法で伝えられます。

+

最後に属性が全て送信された後に、属性の終端を示す 0xFF + が送出されます。この信号は属性の一覧の終わりを示すと同時に、リクエスト + パケットの終端をも示しています。

+
+
+ +
レスポンスパケット構造 +

コンテナがサーバに送り返すことのできるメッセージ:

+ 
+AJP13_SEND_BODY_CHUNK :=
+  prefix_code   3
+  chunk_length  (integer)
+  chunk        *(byte)
+
+
+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)
+
+
詳細 :
+
Send Body Chunk +

チャンクは基本的にはバイナリデータで、ブラウザに直接送られます。

+
+
Send Headers +

ステータスコードとメッセージが通常の HTTP の通信にはあります (例 + 200 と OK)。レスポンスヘッダ名は、 + リクエストヘッダ名と同様の方法でエンコードされます。 + コードと文字列の判別方法の詳細に関しては、上記の header_encoding + を参照してください。 + 一般的なヘッダのコードは :

+ + + + + + + + + + + + + +
名前コードの値
Content-Type0xA001
Content-Language0xA002
Content-Length0xA003
Date0xA004
Last-Modified0xA005
Location0xA006
Set-Cookie0xA007
Set-Cookie20xA008
Servlet-Engine0xA009
Status0xA00A
WWW-Authenticate0xA00B
+

コードかヘッダ文字列の直後には、ヘッダの値がエンコードされます。

+
+
End Response +

リクエスト処理サイクルの終了を知らせます。reuse フラグが真 + (==1) の場合、現在使用している TCP コネクションは次の新しい + リクエストに使えるようになります。reuse が偽 (C のコードでは + 1 以外の全て) の場合は、コネクションを閉じることになります。

+
+
Get Body Chunk +

(ボディのサイズが大きすぎて最初のパケットに収まらない場合や、 + リクエストがチャンク転送された場合などには、) コンテナはリクエストからの + データ読み込み要求をします。サーバ側はそれに対して、最小 + request_length 最大 (8186 (8 Kbytes - 6)) + の範囲で、未転送で残っているリクエストボディの大きさのデータを + 送り返します。
+ ボディにそれ以上データが残っていない場合 (つまりサーブレットが + ボディの最後を超えて読み込もうとした場合) 、サーバは + ペイロード長 0 の空パケット(0x12,0x34,0x00,0x00) + を送り返します。

+
+
+ + + diff --git a/docs/manual/mod/mod_proxy_balancer.xml.ja b/docs/manual/mod/mod_proxy_balancer.xml.ja index 9c914d78dd..0e9bdcd0ab 100644 --- a/docs/manual/mod/mod_proxy_balancer.xml.ja +++ b/docs/manual/mod/mod_proxy_balancer.xml.ja @@ -1,49 +1,49 @@ - - - - - - - - - -mod_proxy_balancer -負荷分散のための mod_proxy 拡張 -Extension -proxy_balancer.c -proxy_balancer_module -2.1 以降 - - -

本モジュールには mod_proxy が必要です。 - HTTP, FTP と AJP13 - プロトコルのロードバランス機能を持っています。

- -

ですから、 ロードバランスを有効にする場合 mod_proxy - と mod_proxy_balancer がサーバに組み込まれて - いなければいけません。

- - 警告 -

安全なサーバにするまでプロクシ機能は有効にしないでください。 - オープンプロキシサーバはあなた自身のネットワークにとっても、 - インターネット全体にとっても危険です。

- - -mod_proxy - - + + + + + + + + + +mod_proxy_balancer +負荷分散のための mod_proxy 拡張 +Extension +proxy_balancer.c +proxy_balancer_module +2.1 以降 + + +

本モジュールには mod_proxy が必要です。 + HTTP, FTP と AJP13 + プロトコルのロードバランス機能を持っています。

+ +

ですから、 ロードバランスを有効にする場合 mod_proxy + と mod_proxy_balancer がサーバに組み込まれて + いなければいけません。

+ + 警告 +

安全なサーバにするまでプロクシ機能は有効にしないでください。 + オープンプロキシサーバはあなた自身のネットワークにとっても、 + インターネット全体にとっても危険です。

+ + +mod_proxy + + -- 2.50.1