1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
|
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="ja" xml:lang="ja"><head><!--
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>mod_proxy_ajp - Apache HTTP サーバ</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
<body>
<div id="page-header">
<p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/directives.html">ディレクティブ</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p>
<p class="apache">Apache HTTP サーバ バージョン 2.2</p>
<img alt="" src="../images/feather.gif" /></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP サーバ</a> > <a href="http://httpd.apache.org/docs/">ドキュメンテーション</a> > <a href="../">バージョン 2.2</a> > <a href="./">モジュール</a></div>
<div id="page-content">
<div id="preamble"><h1>Apache モジュール mod_proxy_ajp</h1>
<div class="toplang">
<p><span>Available Languages: </span><a href="../en/mod/mod_proxy_ajp.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../ja/mod/mod_proxy_ajp.html" title="Japanese"> ja </a></p>
</div>
<div class="outofdate">This translation may be out of date. Check the
English version for recent changes.</div>
<table class="module"><tr><th><a href="module-dict.html#Description">説明:</a></th><td><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> で AJP
をサポートするためのモジュール</td></tr>
<tr><th><a href="module-dict.html#Status">ステータス:</a></th><td>Extension</td></tr>
<tr><th><a href="module-dict.html#ModuleIdentifier">モジュール識別子:</a></th><td>proxy_ajp_module</td></tr>
<tr><th><a href="module-dict.html#SourceFile">ソースファイル:</a></th><td>mod_proxy_ajp.c</td></tr></table>
<h3>概要</h3>
<p>本モジュールには <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> が<em>必要です</em>。
<code>Apache JServ Protocol version 1.3</code> (以降 <em>AJP13</em>)
をサポートします。</p>
<p><code>AJP13</code> プロトコルを扱えるようにするには
<code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> と <code class="module"><a href="../mod/mod_proxy_ajp.html">mod_proxy_ajp</a></code>
をサーバに組み込む必要があります。</p>
<div class="warning"><h3>警告</h3>
<p><a href="#access">安全なサーバにする</a>までプロクシ機能は有効にしないでください。
オープンプロキシサーバはあなた自身のネットワークにとっても、
インターネット全体にとっても危険です。</p>
</div>
</div>
<div id="quickview"><h3 class="directives">ディレクティブ</h3>
<p>このモジュールにディレクティブはありません。</p>
<h3>トピック</h3>
<ul id="topics">
<li><img alt="" src="../images/down.gif" /> <a href="#overviewprotocol">プロトコルの概要</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#basppacketstruct">基本パケット構造</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#rpacetstruct">リクエストパケット構造</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#resppacketstruct">レスポンスパケット構造</a></li>
</ul><h3>参照</h3>
<ul class="seealso">
<li><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></li>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="overviewprotocol" id="overviewprotocol">プロトコルの概要</a></h2>
<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>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="basppacketstruct" id="basppacketstruct">基本パケット構造</a></h2>
<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>
<h3>パケットサイズ</h3>
<p>多くのコードでそうなっているのですが、パケットサイズの最大サイズは
<code>8 * 1024 (8K)</code> です。パケットの実際の長さはヘッダに
エンコードされて入っています。</p>
<h3>パケットヘッダ</h3>
<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>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="rpacetstruct" id="rpacetstruct">リクエストパケット構造</a></h2>
<p>サーバからコンテナへ送られるメッセージが
<em>Forward Request</em> 型の場合 :</p>
<div class="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></div>
<p><code>request_headers</code> は次のような構造になっています :
</p><div class="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></div>
<p><code>属性</code> はオプションで、次のような構造をしています :</p>
<div class="example"><pre>
attribute_name := sc_a_name | (sc_a_req_attribute string)
attribute_value := (string)
</pre></div>
<p>もっとも重要なヘッダは <code>content-length</code> だということに
注意してください。コンテナは次のパケットを探すかどうかを、
それを見て決めるからです。</p>
<h3>Forward Request 要素の詳細な説明
</h3>
<h3>Request prefix</h3>
<p>リクエストについては全て、この値は 2 になります。他の Prefix コードの詳細は
上記をご覧ください。</p>
<h3>Method</h3>
<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>
<h3>protocol, req_uri, remote_addr, remote_host, server_name,
server_port, is_ssl</h3>
<p>これらはまさに文字通りのものです。どれも必要で、リクエストの毎回につき
送られます。</p>
<h3>Headers</h3>
<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>
<div class="note"><h3>注:</h3>
<code>content-length</code> ヘッダはとても重要です。
存在していて非ゼロであれば、リクエストにはボディがある (例えば POST
リクエスト) と推測し、そのボディを取り込むために
直後のパケットを入力ストリームから読み込みはじめます。
</div>
<h3>属性</h3>
<p><code>?</code> プレフィックスで始まる属性 (例 <code>?context</code>)
は。省略可能です。それぞれ属性の型を示す 1 バイトのコードと、
値の文字列が続きます。
これらは順不同で送ることができます (C のコードは常に下の一覧順に
送るようですが) 。
オプションの属性のリストの最後には、特別な終了コードが送られます。
コードの一覧は : </p>
<table>
<tr><td>Information</td><td>Code Value</td><td>Note</td></tr>
<tr><td>?context</td><td>0x01</td><td>未実装
</td></tr>
<tr><td>?servlet_path</td><td>0x02</td><td>未実装
</td></tr>
<tr><td>?remote_user</td><td>0x03</td><td /></tr>
<tr><td>?auth_type</td><td>0x04</td><td /></tr>
<tr><td>?query_string</td><td>0x05</td><td /></tr>
<tr><td>?jvm_route</td><td>0x06</td><td /></tr>
<tr><td>?ssl_cert</td><td>0x07</td><td /></tr>
<tr><td>?ssl_cipher</td><td>0x08</td><td /></tr>
<tr><td>?ssl_session</td><td>0x09</td><td /></tr>
<tr><td>?req_attribute</td><td>0x0A</td><td>Name (the name of the
attribute follows)</td></tr>
<tr><td>?ssl_key_size</td><td>0x0B</td><td /></tr>
<tr><td>are_done</td><td>0xFF</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>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="resppacketstruct" id="resppacketstruct">レスポンスパケット構造</a></h2>
<p>コンテナがサーバに送り返すことのできるメッセージ:</p>
<div class="example"><pre>
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)
</pre></div>
<h3>詳細 :</h3>
<h3>Send Body Chunk</h3>
<p>チャンクは基本的にはバイナリデータで、ブラウザに直接送られます。</p>
<h3>Send Headers</h3>
<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>
<h3>End Response</h3>
<p>リクエスト処理サイクルの終了を知らせます。<code>reuse</code> フラグが真
<code>(==1)</code> の場合、現在使用している TCP コネクションは次の新しい
リクエストに使えるようになります。<code>reuse</code> が偽 (C のコードでは
1 以外の全て) の場合は、コネクションを閉じることになります。</p>
<h3>Get Body Chunk</h3>
<p>(ボディのサイズが大きすぎて最初のパケットに収まらない場合や、
リクエストがチャンク転送された場合などには、) コンテナはリクエストからの
データ読み込み要求をします。サーバ側はそれに対して、最小
<code>request_length</code> 最大 <code>(8186 (8 Kbytes - 6))</code>
の範囲で、未転送で残っているリクエストボディの大きさのデータを
送り返します。<br />
ボディにそれ以上データが残っていない場合 (つまりサーブレットが
ボディの最後を超えて読み込もうとした場合) 、サーバは
ペイロード長 0 の<em>空パケット</em><code>(0x12,0x34,0x00,0x00)</code>
を送り返します。</p>
</div>
</div>
<div class="bottomlang">
<p><span>Available Languages: </span><a href="../en/mod/mod_proxy_ajp.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../ja/mod/mod_proxy_ajp.html" title="Japanese"> ja </a></p>
</div><div id="footer">
<p class="apache">Copyright 2011 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">モジュール</a> | <a href="../mod/directives.html">ディレクティブ</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">用語</a> | <a href="../sitemap.html">サイトマップ</a></p></div>
</body></html>
|
