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
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<meta HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1">
<meta NAME="Author" CONTENT="Stefano Mazzocchi">
<title>Apache JServ Protocol Version 2.1 (AJPv2.1) - June 30, 1998 - Draft</title>
</head>
<body BGCOLOR="#FFFFFF">
<p align="center"><a href="http://java.apache.org/" target="_top"><img SRC="../images/java-apache-project.gif" BORDER="0" WIDTH="609"
HEIGHT="100" ALT="The Java Apache Project"></a></p>
<h1 ALIGN="CENTER">Apache JServ Protocol version 2.1 (AJPv2.1)</h1>
<p ALIGN="CENTER">draft - July 1, 1998</p>
<div align="center"><center>
<table BORDER="0" WIDTH="75%">
<tr>
<td WIDTH="100%" BGCOLOR="#FFFBF0">This is a pre-implementation draft of the Apache JServ
protocol specification, a subject under current discussion within the <a HREF="http://java.apache.org/" target="_top">Java Apache Project</a>. This is a work in progress subject
to revision. <blockquote>
<p>This specification is undergoing implementation experiments but performance tests will
guide further changes to the specs. The implementations at the time will need to adjust to
those changes. </p>
</blockquote>
<p>This document describes an experimental design for a request protocol intended for but
not restricted to use with the Apache JServ servlet engine. </td>
</tr>
</table>
</center></div>
<h2>Abstract</h2>
<p>The original protocol that was built into Apache JServ Servlet Engine was purposely
kept simple for the first implementations of the module. Usage and continuing development
have led to experience indicating needs for significant new features. The Apache JServ
Protocol version 2.1 provides new features such as performance improvements and the
ability for the servlet engine to make intermediate requests back to the HTTP for more
information about its environment. The protocol is built on top a connection and depends
only on the ability of two ends to communicate between each other in a full duplex manner.
This is kept sufficiently generalized that the connection layer can be of any type, even
if first implementation will based on plain TCP/IP connections. </p>
<h2>Glossary</h2>
<dl>
<dt><i>Client</i></dt>
<dd>The HTTP server process/thread becomes the <i>client</i> in the context of this protocol
because it initiates the request and waits for the response. </dd>
<dt><i>Connection</i></dt>
<dd>A finite-duration link between client and server, upon which all transmissions occur.
This can theoretically be over any reliable ordered-stream transport but is expected to
usually be delivered over a TCP-based socket. </dd>
<dt><i>Error</i></dt>
<dd>A fatal condition forcing termination of the request. Errors reported to the client
SHOULD be logged by the client. </dd>
<dt><i>Octet</i></dt>
<dd>An 8-bit quantity, or byte. </dd>
<dt><i>Server</i></dt>
<dd>The Servlet Engine performs the server function in the context of the this protocol. </dd>
<dt><i>Warning</i></dt>
<dd>An abnormal but non-fatal condition which allows processing of the request to continue.
Warnings reported to the client SHOULD be logged by the client. </dd>
</dl>
<p>The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to
be interpreted as described in <a HREF="#refs">RFC 2119</a>.</p>
<h2>The Original JServ Protocol (AJPv1)</h2>
<p>The original protocol (<a HREF="#refs">AJPv1</a>), written by Alexei Kosut at Organic
Online in July 1997, was deliberately kept simple according to the needs of the project at
the time.</p>
<p>The protocol included a "startup" phase where the Apache Web Server would
start the JServ Servlet Engine process and give it an initial setting for the
authentication that will be used thereafter by all servlet requests. There was also a
"manual" mode for the servlet engine, where no authentication would be required.
This is potentially dangerous if used without providing other protection against
intruders.</p>
<p>Then for each request, the HTTPD process would connect to the Servlet Engine via a
socket, and then send a series of ASCII text lines with request headers. The Servlet
Engine would then respond with the entire response when it was done.</p>
<p>Usage of the JServ protocol has brought about more experience in this problem domain
and the following issues:
<ul>
<li>The servlet output is always buffered. But unbuffered output is desirable in many cases.
</li>
<li>Developers have expressed a desire to be able to send requests back to the Apache Web
Server for various processing with configuration information only available to the HTTPD.
(i.e. subrequest handling, URL/path evaluation) </li>
<li>The socket setup overhead has been identified as a potential performance bottleneck. </li>
<li>Logging messages for the Apache Web Server can only be sent with the request headers. If
they're not ready at that time for one request, they must be saved and sent during the
header phase of the next request, guaranteeing that any late log messages for the last
request will be lost. </li>
</ul>
<p>One option to avoid the socket setup overhead was based on the
multiple-requests-per-socket goal as in W3C's <a HREF="#refs">MUX</a> protocol. However
MUX was determined to have excessive overhead for this purpose because the support for
arbitrary protocols introduces generalization not necessary in this environment. Even a
lighter version of MUX developed into AJPv2 was considered too complex and its performance
improvement too small compared to the implementation effort due to its complexity.</p>
<h2>Overview</h2>
<p>AJPv2.1 is a packet oriented protocol and all data passed through the AJPv2.1
connection must be encapsulated into one or more packets. This form of <i>binary</i>
behavior was chosen instead of more readable <i>plain text</i> protocol (such as HTTP)
because more performant (less traffic is generated) and faster to implement (packet types
are better understood by machines that text string). The packet format was kept small (32
bits) for performance reasons and while some packets MUST contain all data they carry into
a single packet, a few may divide their payload into one or more successive packets
(Request and Response). This was needed to allow payloads bigger than 16 Mb, a big value
but suppose to be restricting for some necessities and for future communication
enhancements.</p>
<p>This protocol uses an authentication to secure connections and to deny possible
requests bypassing web server security: if properly setup (see Security for more info on
this topic), AJPv2.1 is considered secure and therefore protects the servlet engine from
untrusted requests and/or attacks.</p>
<p>Since one of the main issues AJPv1 was not addressing was performance and socket
creation was found as one of the bottlenecks, this protocol is based on the idea of
"recyclable" sockets, which may be reused instead of being closed and created
when needed (see Socket Recycling for more info on this topic).</p>
<p>To make this possible, requests (and not connections) drive protocol behavior. Each
connection is considered idle if authenticated but not yet received a packet starting the
request. Once a connection is used by a request, it SHOULD not be used for other requests
since unknown state transitions may arise. This forces the protocol to be
single-request-per-connection oriented (unlike MUX or AJPv2.0 that were
multiple-requests-per-connection oriented) and uses socket recycling to avoid socket
creation overhead, instead of multiplexing multiple requests on a single connection.</p>
<p>While this clearly increases the number of simultaneous connections that may be needed
to fulfill the request flow a web server generates, but clearly simplifies the work needed
to implement this protocol and increases its performance since little processing is needed
on top of the connection protocol (i.e. TCP/IP).</p>
<p>Each request begins with the request environment, including information analogous to
what is found in a <a HREF="#refs">CGI</a> request's environment. During the course of
processing the request, either the server or client may send some "function
requests" to each other. (see Functions for more info on this topic)</p>
<p>As the server completes parts of the primary request's result, it will send them as
response packets. When the server completes its processing, it signals the end of the
request by terminating the response.</p>
<p>At any point when there are no open requests, it is the option of both the client and
the server to close the connection for resource management, because file descriptors are
assumed to be a finite resource on both sides. </p>
<h2>Data Packet Format</h2>
<p>All data sent on the full duplex connection between the client and server MUST follow
this structure:
<ul>
<li>Data is sent in packets formed by a header describing some info about the packet and a
data length and data payload. </li>
<li>All packets MUST follow big endian style ("network order"). </li>
<li>The packet header is always 32 bits long and follow this format: <ul>
<li>Octet 0 (8 bits) contains the packet type and subtype <ul>
<li>The least significant 4 bits (Bits 0-3) indicate the "packet type" of the
packet using an unsigned value. </li>
<li>The most significant 4 bits (Bits 4-7) indicate the subtype of the packet using an
unsigned value. </li>
</ul>
</li>
<li>Octet 1-3 (24 bits) set the length of the data payload carried by the packet itself in
octets and MAY be zero. </li>
</ul>
</li>
<li>Octet 4 is "data octet 0" and Octet "data length + 3" is the last
"data octet". </li>
</ul>
<div align="center"><center>
<table BORDER="1" CELLPADDING="2" CELLSPACING="0" BGCOLOR="#FFFFFF">
<tr>
<td colspan="13"><p ALIGN="LEFT"><b>Packet Format</b> </td>
</tr>
<tr>
<th BGCOLOR="#C0C0C0">Octet</th>
<td COLSPAN="8" BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><b>0</b> </td>
<td WIDTH="80" BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><b>1</b> </td>
<td WIDTH="80" BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><b>2</b> </td>
<td WIDTH="80" BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><b>3</b> </td>
<td WIDTH="80" BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><b>4 - (n+3)</b> </td>
</tr>
<tr>
<th HEIGHT="20" BGCOLOR="#C0C0C0">Bits</th>
<td HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">0 </td>
<td HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">1 </td>
<td HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">2 </td>
<td HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">3 </td>
<td HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">4 </td>
<td HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">5 </td>
<td HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">6 </td>
<td WIDTH="8" HEIGHT="20" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">7 </td>
<td HEIGHT="20" COLSPAN="3" BGCOLOR="#FFFFCC"></td>
<td WIDTH="80" HEIGHT="20" BGCOLOR="#FFFFCC"></td>
</tr>
<tr>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Contents</b> </td>
<td COLSPAN="4" BGCOLOR="#FF9999"><p ALIGN="CENTER">Type </td>
<td COLSPAN="4" BGCOLOR="#FFCCCC"><p ALIGN="CENTER">Subtype </td>
<td COLSPAN="3" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">Data Length </td>
<td WIDTH="80" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">Data </td>
</tr>
</table>
</center></div>
<h2>Packet Types and Subtypes</h2>
<p>Packet types MUST have a corresponding subtype and valid values are shown in the
following table:</p>
<div align="center"><center>
<table BORDER="1" CELLPADDING="3" CELLSPACING="0" width="100%">
<tr>
<td colspan="7"><p ALIGN="LEFT"><b>Packet Type/Subtype Definition Table</b> </td>
</tr>
<tr>
<th BGCOLOR="#C0C0C0">Type</th>
<th BGCOLOR="#C0C0C0">Type Description</th>
<th BGCOLOR="#C0C0C0">Subtype</th>
<th BGCOLOR="#C0C0C0">Originator</th>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Bit Map</b> </td>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Data Length</b> </td>
<th BGCOLOR="#C0C0C0"><p ALIGN="LEFT">Subtype Description </th>
</tr>
<tr>
<td ROWSPAN="4" BGCOLOR="#FFFBF0"><p ALIGN="CENTER">0 </td>
<td ROWSPAN="4" BGCOLOR="#FFFBF0"><p ALIGN="CENTER">Authentication </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">0 </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">Server </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><tt>0000-0000</tt> </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">[5 - 16777215] </td>
<td BGCOLOR="#FFFBF0">Server authentication</td>
</tr>
<tr>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">1 </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">Client </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><tt>0001-0000</tt> </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">16 </td>
<td BGCOLOR="#FFFBF0">Client authentication</td>
</tr>
<tr>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">2 </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">Server </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><tt>0010-0000</tt> </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">0 </td>
<td BGCOLOR="#FFFBF0">Authentication success</td>
</tr>
<tr>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">3 </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">Server </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER"><tt>0011-0000</tt> </td>
<td BGCOLOR="#FFFBF0"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#FFFBF0">Authentication failure</td>
</tr>
<tr>
<td ROWSPAN="2" BGCOLOR="#FF9999"><p ALIGN="CENTER">1 </td>
<td ROWSPAN="2" BGCOLOR="#FF9999"><p ALIGN="CENTER">Request </td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER">0 </td>
<td ROWSPAN="2" BGCOLOR="#FF9999"><p ALIGN="CENTER">Client </td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER"><tt>0000-0001</tt> </td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#FF9999">Request (data block still not complete)</td>
</tr>
<tr>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER">1 </td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER"><tt>0001-0001</tt> </td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#FF9999">Request (data block complete)</td>
</tr>
<tr>
<td ROWSPAN="3" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">2 </td>
<td ROWSPAN="3" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">Function </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">0 </td>
<td ROWSPAN="3" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">Either </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><tt>0000-0010</tt> </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#FFFFCC">Function call</td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">1 </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><tt>0001-0010</tt> </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#FFFFCC">Function success</td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">2 </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><tt>0010-0010</tt> </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#FFFFCC">Function failure</td>
</tr>
<tr>
<td ROWSPAN="5" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">3 </td>
<td ROWSPAN="5" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">Response </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">0 </td>
<td ROWSPAN="5" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">Server </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"><tt>0000-0011</tt> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#CCFFCC">Response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">1 </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"><tt>0001-0011</tt> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#CCFFCC">Logs (newline-delimited)</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">2 </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"><tt>0010-0011</tt> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#CCFFCC">Warning</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">3 </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"><tt>0011-0011</tt> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#CCFFCC">Error</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">4 </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"><tt>0100-0011</tt> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">0 </td>
<td BGCOLOR="#CCFFCC">End of response</td>
</tr>
<tr>
<td ROWSPAN="3" BGCOLOR="#99CCFF"><p ALIGN="CENTER">15 </td>
<td ROWSPAN="3" BGCOLOR="#99CCFF"><p ALIGN="CENTER">Protocol </td>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER">0 </td>
<td ROWSPAN="3" BGCOLOR="#99CCFF"><p ALIGN="CENTER">Either </td>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER"><tt>0000-0100</tt> </td>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER">0 </td>
<td BGCOLOR="#99CCFF">Close connection</td>
</tr>
<tr>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER">1 </td>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER"><tt>0001-0100</tt> </td>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER">0 </td>
<td BGCOLOR="#99CCFF">Connection closed</td>
</tr>
<tr>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER">2 </td>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER"><tt>0010-0100</tt> </td>
<td BGCOLOR="#99CCFF"><p ALIGN="CENTER">[0 - 16777215] </td>
<td BGCOLOR="#99CCFF">Fatal protocol error</td>
</tr>
</table>
</center></div>
<p>The tables fields are as follows. </p>
<blockquote>
<ul>
<li><em>Type</em> contains the the numbers to be used in the packet type field of the packet
header. </li>
<li><em>Type Description</em> contains a one-word description which will be used as a name
for that type of packet in following sections. </li>
<li><em>Originator</em> states whether combination of packet type and subtype may originate
with the client, server or either one. A packet with that type and subtype combination
MUST originate only on the side(s) allowed in the table. </li>
<li><em>Subtype</em> contains the numbers to be used in the packet subtype field of the
packet header. </li>
<li><i>Bitmap</i> shows the bit map found into the first octet of the packet header (LSB is
on the right side of the table) </li>
<li><i>Data Length</i> contains the data length in octets the referring packet is allowed to
carry (16Mb is maximum allowed packet size by the header format, given its 24 bits for
data length) </li>
<li><em>Subtype Description</em> contains a description of the meaning of a packet with that
specific combination of type and subtype. </li>
</ul>
</blockquote>
<p>Any packet with packet type, subtype, origination or size not as shown in the table
above constitutes a fatal protocol error.</p>
<p>All packets will be referred as the couple<i> </i>[n,m] where <i>n</i> will be the
packet type and <i>m</i> the subtype. </p>
<blockquote>
<h3>Authentication Packets [0,x]</h3>
<ul>
<li>packet [0,0] contains an array of random-value octets used as authentication challenge
string. This is the first packet sent by the server upon establishment of each connection.
The length MUST be at least 5 octets to force a reasonable security on the connection
authentication. A new random challenge MUST be chosen for each connection. </li>
<li>Packet [0,1] contains the authentication string in response of server challenge. The
length MUST be 16 octets since this is the length of the MD5 hash needed to authenticate
the socket. </li>
<li>Packet [0,2] acknowledges the client that authentication was successful and connection
was established properly. This packet MUST NOT contain any data and MUST have its data
length set to zero. </li>
<li>Packet [0,3] indicates authentication failed and connection could not be established.
Any data placed in this packet is OPTIONAL but MAY be used to contain a message explaining
the failure of such operation. </li>
</ul>
<p>See the section on Security for more details.</p>
<h3>Request Packets [1,x]</h3>
<ul>
<li>packet [1,0] contains a fragment of the request data block, indicating others (at least
one) request packets will be needed by the server to obtain all request data. This packet
SHOULD be used only when request fragmenting is needed or when request data is bigger then
16 Mb. </li>
<li>packet [1,1] contains all the request data if received alone, or completes the request
data if received after one or more [1,0] packet. This packet activates the connection
receiving it and SHOULD lock the connection so that no other requests may be done before
response has been terminated. </li>
</ul>
<p>See the section on Request for more details on request data format. </p>
<h3>Function Request Packets [2,x]</h3>
<ul>
<li>packet [2,0] contains the name of the function that the other side must execute and the
value passed to it. </li>
<li>packet [2,1] contains the return value of the function call or nothing is function is
not supposed to return a value. </li>
<li>packet [2,2] indicates the function requested failed and MAY contain a message
explaining the failure of such operation. This packet MUST be sent back to caller if the
function requested could not be processed (function not enabled, not supported, or some
exceptional behavior was caused by its execution). </li>
</ul>
<p>See the section of Functions for details on function request format.</p>
<h3>Response Packets [3,x]</h3>
<ul>
<li>packet [3,0] contains a response data block. There MAY be more than one [3,0] packet on
the same request process. A packet [3,4] will be used to indicate the end of the response
data block. The server MAY fragment the response data block without any constrain, this to
allow unbuffered response, or sending of other packets during a response phase. </li>
<li>packet [3,1] contains one or more log entry lines from the server to the client. This is
intended as routine per-request logging while warnings and errors should use the packets
listed below specifically for those purposes. There MAY be more than one log entry per
packet, delimited by newlines. And there MAY be more than one [3,1] packet sent from the
server to the client within a request process. </li>
<li>packet [3,2] contains a text message describing the warning condition. This intended for
logging on the client. </li>
<li>packet [3,3] contains a text message describing why a request failed. This intended for
logging on the client and may be used to describe the error on any error messages
forwarded to the user by the client. </li>
<li>packet [3,4] indicates the end of request and unlocks the connection. Any further
response packet sent from the server before another request is received SHALL be treated
as a fatal protocol error, since the connection may handle only a request process at a
time. </li>
</ul>
<p>See the section on Response for details on response data format.</p>
<h3>Protocol Packets [15,x]</h3>
<ul>
<li>Packet [15,0] forces the receiver to close the connection receiving the packet. This
packet MUST NOT contain any data and MUST have its data length set to zero. </li>
<li>Packet [15,1] indicates a fatal failure due to a protocol error. It also indicates that
the originating process is closing the connection. Any data placed in a protocol error
packet is OPTIONAL and MAY be used for debugging purposes. </li>
</ul>
</blockquote>
<h2>Request</h2>
<p>Request metadata may be sent by the client in one or more request packets [1,0] that
the server SHALL treat as a single data block. Request data block MAY be fragmented with
no specific constrains. Packet [1,1] terminates the request data block and activates
request processing on server side.</p>
<p>The request consists of two parts, request headers and the request entity. Request
entity MAY NOT be present.</p>
<h3>Request headers</h3>
<blockquote>
<p>The headers to be set for the request follow MIME format: </p>
<blockquote>
<p><tt>"<header name>: <header value>'crlf'"</tt> </p>
</blockquote>
<p>where 'crlf' are carriage return (hex value 0x0D), line feed (hex value 0x0A)
characters indicating the end of the single header. This poses a constrain on header
values that MUST NOT contain these characters in the given order.When the last header has
been sent, a blank line (another couple 'crlf' alone) should be sent.</p>
<p>All headers found on the following list MUST be sent only if their value is both
meaningful and known by the client at request time. If value is not known or not
meaningful, the variable MUST not be passed, allowing the use of the empty header value as
a meaningful one. Note that header names will be treated as case dependent.. </p>
<div align="center"><center><table BORDER="1" CELLPADDING="2" CELLSPACING="0">
<tr>
<td colspan="3"><p ALIGN="LEFT"><b>Request Headers List</b> </td>
</tr>
<tr>
<td WIDTH="113" BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Header Group</b> </td>
<td WIDTH="161" BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Header Name</b> </td>
<td WIDTH="423" BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Description</b> </td>
</tr>
<tr>
<td WIDTH="113" ROWSPAN="16" BGCOLOR="#FFFFFF"><p ALIGN="CENTER">CGI Environment </td>
<td WIDTH="161" BGCOLOR="#FFFFFF">AUTH_TYPE</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The type of authentication used</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">CONTENT_LENGTH</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The length of the request entity</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">CONTENT_TYPE</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The media type of the request entity</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">DOCUMENT_ROOT</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The client's main document root</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">PATH_INFO</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">Extra URI path information</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">PATH_TRANSLATED</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The translated path info</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">QUERY_STRING</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The query arguments</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">REQUEST_METHOD</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The method used for the request</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">REMOTE_USER</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The authenticated username used for the request</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">REMOTE_ADDR</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The IP address of the requesting host</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">REMOTE_HOST</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The hostname of the requesting host</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">SCRIPT_NAME</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The URI portion that refers to the servlet</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">SERVER_NAME</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The hostname of the server</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">SERVER_PORT</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The port number of the server</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">SERVER_PROTOCOL</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The protocol used for the request</td>
</tr>
<tr>
<td WIDTH="161" BGCOLOR="#FFFFFF">SERVER_SOFTWARE</td>
<td WIDTH="423" BGCOLOR="#FFFFFF">The name of the server software</td>
</tr>
<tr>
<td WIDTH="113" BGCOLOR="#FFFFFF"><p ALIGN="CENTER">HTTP Header </td>
<td WIDTH="161" BGCOLOR="#FFFFFF"> </td>
<td WIDTH="423" BGCOLOR="#FFFFFF">All headers sent with the HTTP request</td>
</tr>
</table>
</center></div>
</blockquote>
<h3>Response entity</h3>
<blockquote>
<p>If the request entity is present, it is sent after the request headers with no further
formatting.</p>
</blockquote>
<h2>Function</h2>
<p>Each function call packet [2,0] contains a single request for a function call. This
allows one side to call functions on the other using the same transmission channel used
for request/response processing. These functions may well be called during request
processing, for example to gather information not available at request startup, or on an
open, idle connection, for example to signal the other side to restart/shutdown.</p>
<p>The data contained into the packet [2,0] follows a binary format: </p>
<blockquote>
<p><tt>"<function code (single octet)><function value>"</tt> </p>
</blockquote>
<p>If function is successful, data contained by the packet [2,1] is what the function
returned with no further formattation (a data length of zero means the function returned
nothing or void), otherwise a packet [2,2] is received containing a message explaining the
failure of the called function.</p>
<p>Here is a list of defined functions with their code: </p>
<div align="center"><center>
<table BORDER="1" CELLPADDING="3" CELLSPACING="0">
<tr>
<td colspan="2"><p ALIGN="LEFT"><b>Functions List</b> </td>
</tr>
<tr>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Function Code</b> </td>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Description</b> </td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><b>0</b> </td>
<td BGCOLOR="#FFFFCC">Applies alias rules to the specified virtual path and returns the
corresponding real path</td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><b>1</b> </td>
<td BGCOLOR="#FFFFCC">Maps a file name to its MIME type</td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><b>2</b> </td>
<td BGCOLOR="#FFFFCC">Returns the content of a file specified by a virtual path</td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><b>3</b> </td>
<td BGCOLOR="#FFFFCC">Returns the content of a file specified by a real path</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"><b>4-253</b> </td>
<td BGCOLOR="#CCFFFF">Reserved for future use (must return "function not implemented)</td>
</tr>
<tr>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER"><b>254</b> </td>
<td BGCOLOR="#FFCCCC">Signals receiver to cleanup and restart</td>
</tr>
<tr>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER"><b>255</b> </td>
<td BGCOLOR="#FF9999">Signals receiver to shutdown</td>
</tr>
</table>
</center></div>
<p>Functions with codes ranging from 4 to 253 SHOULD return a [2,2] packet containing
"Function not defined", while functions described above but not implemented
SHOULD return "Function not implemented". Functions that are implemented but
cannot execute the requested function SHOULD return a detailed message explaining the such
impossibility or at least a "Function not available" message. </p>
<h2>Response</h2>
<p>As for requests, response metadata may be sent by the server in one or more response
packets [3,0] that the client SHALL treat as a single data block. Response data block MAY
be fragmented with no specific constrains. Packet [3,1] terminates the response data
block, while Packet [3,5] terminates the request process. This packet duplicity is needed
to allow the sending of other response packets after the response has been fully
processed, thus reducing the transmission overhead of the response data to the client.</p>
<p>The response consists of two parts, response headers and the response entity. Response
entity MAY NOT be present.</p>
<h3>Response headers</h3>
<blockquote>
<p>The headers to be set for the response follow MIME format: </p>
<blockquote>
<p><tt>"<header name>: <header value>'crlf'"</tt> </p>
</blockquote>
<p>where 'crlf' are carriage return (hex value 0x0D), line feed (hex value 0x0A)
characters indicating the end of the single header. This poses a constrain on header
values that MUST NOT contain these characters in the given order.When the last header has
been sent, a blank line (another couple 'crlf' alone) should be sent.</p>
<p>All headers found on the following list MUST be sent only if their value is both
meaningful and known by the server at response time. If value is not known or not
meaningful, the header MUST not be passed, allowing the use of the empty header value as a
meaningful one.</p>
<div align="center"><center><table BORDER="1" CELLPADDING="2" CELLSPACING="0">
<tr>
<td colspan="3"><p ALIGN="LEFT"><b>Response Headers List</b> </td>
</tr>
<tr>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Header Name</b> </td>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Header Format</b> </td>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Description</b> </td>
</tr>
<tr>
<td>Status</td>
<td><tt>"Status: <code> <string>"</tt></td>
<td>sets the response status to <code>, with a status message of <string></td>
</tr>
</table>
</center></div>
</blockquote>
<h3>Response entity</h3>
<blockquote>
<p>The entity is the data block generated by the request process and, if present, it is
sent with no further formatting. </p>
</blockquote>
<h2>Security</h2>
<p>The "secret integer" authentication algorithm of AJPv1 has not been carried
forward to AJPv2.1 because considered not secure.</p>
<p>The AJPv2.1 authentication algorithm depends on all clients and the server having
access to a secret file or string with identical contents. This is based on the assumption
that the administration of the AJPv2.1 client and server systems are either the same or in
cooperation with each other.</p>
<p>This algorithm uses MD5 hashing but no strong cryptography, and is therefore exportable
under cryptography restrictions for the United States, France and Russia in effect as of
July, 1998. It is able to verify that both sides possess secret text (analogous to a
password) without passing any of it in the clear over the network.
<ul>
<li><b>Client side</b> <ul>
<li>receive a packet [0,0] from the server carrying a challenge string (C). Packet data
length is used to retrieve the challenge string length. </li>
<li>obtain the shared secret S from a file or the client configuration </li>
<li>concatenate C and S </li>
<li>compute the MD5 hash of the resulting string </li>
<li>send the MD5 hash to the server in the authentication string as a packet [0,1] </li>
</ul>
</li>
<li><b>Server side:</b> <ul>
<li>generate a challenge string of random octets C with length defined using local
configuration parameters (minimum length is forced for security reasons to be at least 5
octets) and send it to the client using a [0,0] packet with data length given by the
challenge string length. Packet [0,0] MUST contain only the challenge string and its data
length MUST be the same as the challenge string length. </li>
<li>save C right after sending it to the client </li>
<li>obtain the shared secret S from a file or the server configuration </li>
<li>concatenate C and S </li>
<li>compute the MD5 hash of the resulting string </li>
<li>receive the MD5 hash from the client, as data carried by a packet [0,1] </li>
<li>if the resulting MD5 hash and the received MD5 hash ARE the same, send a Packet [0,2] to
the client to acknowledge authentication success. This packet MUST have zero data length
and MUST no carry any other information. </li>
<li>if the resulting MD5 hash and the received MD5 hash ARE NOT the same, send a Packet
[0,3] to client to acknowledge authentication failure. Any data placed in this packet is
OPTIONAL but MAY be used to contain a message explaining the authentication failure. </li>
</ul>
</li>
</ul>
<p>The shared secret is an arbitrary-length string (which does not necessarily need to be
ASCII text - it could be any binary file.) The only limitation on the shared secret is
that the longer the string, the more processing will be necessary to compute an MD5 hash
with it.</p>
<h2>Security Hazards</h2>
<p>Security is always a big issue for servers, since only trusted clients should be able
to use and interact with the server. This protocol implements an authentication algorithm
that is considered safe for most needs (at least as safe as MD5, on top of which it's
constructed), allowing a client to authenticate a connection only if it knows the secret
key of the server. Since this secret key is not passed onto the network and MD5 is
considered computationally infeasible if suggested challenge sizes are used over time,
this gives us enough confidence on this protocol.</p>
<p>Since the security of a transmission is granted by the whole protocol stack, problems
may come out if we analyze the security holes that may be carried by the underlying
transport protocols. (We concentrate on TCP/IP protocol since it will be the one used by
the AJP implementations)</p>
<p>Here follows a list of possible security hazards and suggested security improvements
and/or solutions to prevent them.</p>
<blockquote>
<h3>Intrusion</h3>
<p>Servlet execution is protected by the web server since the servlet engine does not
impose any restriction on servlet requests coming from authenticated connection because
they are considered trusted and secure. Intruders may want to bypass this security to
execute servlets and gather information about the system or data contained (administration
servlets may have full access to databases or to system resources such as password lists,
system configurations, or other private information that need to remain secret).</p>
<p>The authentication algorithm depends on good pseudo random number generation, since
difference between each authentication handshake is given by the variability of the
challenge string. The weakness of pseudo random number generation (the prevision of the
random number sequence) is not an issue since the challenge string is sent to everyone,
even possible intruders. On the other hand, the pseudo random number generator MUST
guarantee the variability of the challenge string since this is the key for authentication
safety. There is a very small chance that any given challenge could be used again for
another connection. If this were to occur a sniffed packet could be used to answer the
authentication. For this reason a minimum of 5 octets of challenge string were forced.</p>
<p>Many more recommendations and ideas in the area of impacts of pseudo random number
generation on security can be found in <a HREF="#refs">RFC 1750, "Randomness
Recommendations for Security"</a></p>
<p><font COLOR="#990000"><b>Warning:</b> this algorithm is as vulnerable as the secret
file or string contents. For this reason, they SHOULD be adequately protected from
unauthorized users by any security measures available.</font></p>
<p><font COLOR="#006600"><b>Solutions for developers:</b> use good pseudo random number
generators. Implement a IP address filter list to deny connection to addresses not
allowed.</font></p>
<p><font COLOR="#006600"><b>Solutions for end users:</b> keep your secret file protected
from unauthorized users and increment challenge string length to enhance security keeping
in mind that the bigger the challenge strings the slower the connection authentication.
Configure the IP addresses filter list to match the addresses of the trusted clients.</font></p>
<h3>Denial of Service</h3>
<p>Another potential security hazard is the ability of causing the protocol stall by
requesting connections without sending back the authentication response to the servlet
engine. Since connections are a finite resource, this could cause <i>denial of connection</i>
if some connections were still open but no more were available, or <i>denial of service</i>
if all connections were stalled by the attack.</p>
<p><font COLOR="#006600"><b>Solutions for developers:</b> implement a time-out on
authentication handshake, giving the ability to the server to drop a connection if the
challenge response is not received in a configurable number of seconds. Implement a IP
address filter list to deny connection to addresses not allowed.</font></p>
<p><font COLOR="#006600"><b>Solutions for end users:</b> configure this time-out on
authentication handshake to match closely your network/systems performance. Configure the
IP addresses filter list to match the addresses of the trusted clients.</font></p>
<h3>Packet Sniffing</h3>
<p>This protocol does not encrypts the data sent through the connection. Therefore it is
possible to sniff protocol packets and retrieve the information that is being sent. Due to
protocol complexity and legal restrictions on encryption software, packet masking is not
implemented in current version of the protocol.</p>
<p><font COLOR="#006600"><b>Solutions for end users:</b> since the transport protocol is
transparent for AJP, the use of secured sockets, or even placing both clients and servers
on a secured network may be effective solutions against this security hazard. Another
option would be that of placing both the client and the server on the same machine,
restricting the sniffing capabilities to users of that machine that may be limited and
controlled.</font></p>
<h3>IP Spoofing</h3>
<p>This protocol authenticates connections only when they are created. An intruder capable
of <i>faking</i> IP addresses on its packets, may enter an authenticated connection and
send packets behaving like the authenticated other side. Such kind of attack cannot
retrieve information from the server since spoofed packets don't get returned to the
attacker (as long as routing tables don't get altered) but to the authenticated client
(that will probably return a Fatal Protocol Error and close the connection), but being
able to make requests bypassing authentication could be a very dangerous thing (i.e.
servlets executing free form queries on database may get used to destroy the whole
database, or file uploading servlets may get used to fill up disk space causing denial of
service or unpredictable behavior)</p>
<p><font COLOR="#006600"><b>Solutions for end users</b>: the solutions used to avoid
packet sniffing may be used effectively also against this kind of attacks.</font></p>
</blockquote>
<h2>State Transitions</h2>
<div align="center"><center>
<table BORDER="1" CELLPADDING="2" CELLSPACING="0" WIDTH="100%" BGCOLOR="#FFFFFF">
<tr>
<td colspan="7"><p ALIGN="LEFT"><b>Client Side State Transition Table</b> </td>
</tr>
<tr>
<th BGCOLOR="#C0C0C0">State</th>
<th BGCOLOR="#C0C0C0">Event</th>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Packet<br>
Received</b> </td>
<th COLSPAN="2" BGCOLOR="#C0C0C0">Action</th>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Packet<br>
Sent</b> </td>
<th BGCOLOR="#C0C0C0">New State</th>
</tr>
<tr>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER"><b>closed</b> </td>
<td BGCOLOR="#FF9999"> </td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#FF9999">open connection</td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FFCCCC">unauthenticated</td>
</tr>
<tr>
<td ROWSPAN="2" BGCOLOR="#FFCCCC"><p ALIGN="CENTER"><b>unauthenticated</b> </td>
<td BGCOLOR="#FFCCCC">receive authentication challenge</td>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER">[0,0] </td>
<td COLSPAN="2" BGCOLOR="#FFCCCC">send authentication response</td>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER">[0,1] </td>
<td BGCOLOR="#FFFFCC">waiting for authentication</td>
</tr>
<tr>
<td BGCOLOR="#FFCCCC">receive other</td>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#FFCCCC">close connection</td>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td ROWSPAN="3" BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><b>waiting for authentication</b> </td>
<td BGCOLOR="#FFFFCC">receive authentication success</td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[0,2] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC">receive authentication failure</td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[0,3] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC">close connection</td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td BGCOLOR="#FFFFCC">receive other</td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC">close connection</td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td ROWSPAN="9" BGCOLOR="#CCFFCC"><p ALIGN="CENTER"><b>open</b> </td>
<td BGCOLOR="#CCFFCC"> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">send request fragment</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[1,0] </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC"> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">send final request fragment</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[1,1] </td>
<td BGCOLOR="#CCFFFF">waiting for response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC"> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">send function request</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[2,0] </td>
<td BGCOLOR="#FFCC99">waiting for function response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC"> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">send close connection</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,0] </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td ROWSPAN="2" BGCOLOR="#CCFFCC">receive function request</td>
<td ROWSPAN="2" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[2,0] </td>
<td ROWSPAN="2" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">evaluate function </td>
<td BGCOLOR="#CCFFCC">on success, send response</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[2,1] </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC">on failure, send error message</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[2,2] </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC">receive close connection</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,0] </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">close connection</td>
<td BGCOLOR="#CCFFCC"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC">receive protocol error</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,1] </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">close connection</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC">receive other</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">send protocol error, close connection</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,1] </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td ROWSPAN="11" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"><b>waiting for response</b> </td>
<td BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#CCFFFF"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send close connection</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,0] </td>
<td BGCOLOR="#CCFFFF">closed</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive response</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,0] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFFF">waiting for response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive log</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,1] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFFF">waiting for response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive warning</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,2] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFFF">waiting for response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive error</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,3] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFFF">waiting for response</td>
</tr>
<tr>
<td ROWSPAN="2" BGCOLOR="#CCFFFF">receive function request</td>
<td ROWSPAN="2" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[2,0] </td>
<td ROWSPAN="2" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">evaluate function </td>
<td BGCOLOR="#CCFFFF">on success, send response</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[2,1] </td>
<td BGCOLOR="#CCFFFF">waiting for response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">on failure, send error message</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[2,2] </td>
<td BGCOLOR="#CCFFFF">waiting for response</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive end of response</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,4] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive close connection</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,0] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">close connection</td>
<td BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive protocol error</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,1] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">close connection</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">receive other</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send protocol error, close connection</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,1] </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td ROWSPAN="6" BGCOLOR="#FFCC99"><p ALIGN="CENTER"><b>waiting for function response</b> </td>
<td BGCOLOR="#FFCC99"> </td>
<td BGCOLOR="#FFCC99"> </td>
<td COLSPAN="2" BGCOLOR="#FFCC99">send close connection</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER">[15,0] </td>
<td BGCOLOR="#CCFFCC">closed</td>
</tr>
<tr>
<td BGCOLOR="#FFCC99">receive function response</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER">[2,1] </td>
<td COLSPAN="2" BGCOLOR="#FFCC99"> </td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#FFCC99">receive function failure</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER">[2,2] </td>
<td COLSPAN="2" BGCOLOR="#FFCC99"> </td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#FFCC99">receive close connection</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER">[15,0] </td>
<td COLSPAN="2" BGCOLOR="#FFCC99">close connection</td>
<td BGCOLOR="#FFCC99"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td BGCOLOR="#FFCC99">receive protocol error</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER">[15,1] </td>
<td COLSPAN="2" BGCOLOR="#FFCC99">close connection</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
<tr>
<td BGCOLOR="#FFCC99">receive other</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#FFCC99">send protocol error, close connection</td>
<td BGCOLOR="#FFCC99"><p ALIGN="CENTER">[15,2] </td>
<td BGCOLOR="#FF9999">closed</td>
</tr>
</table>
</center></div><div align="center"><center>
<table BORDER="1" CELLPADDING="2" CELLSPACING="0" WIDTH="100%">
<tr>
<td colspan="7"><p ALIGN="LEFT"><b>Server State Transitions Table</b> </td>
</tr>
<tr>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>State</b> </td>
<td WIDTH="188" BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Event</b> </td>
<td WIDTH="68" BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Packet Received</b> </td>
<td COLSPAN="2" BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Action</b> </td>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>Packet Sent</b> </td>
<td BGCOLOR="#C0C0C0"><p ALIGN="CENTER"><b>New State</b> </td>
</tr>
<tr>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER"><b>listening </b></td>
<td WIDTH="188" BGCOLOR="#FF9999">connection is requested</td>
<td WIDTH="68" BGCOLOR="#FF9999"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#FF9999">send authentication challenge</td>
<td BGCOLOR="#FF9999"><p ALIGN="CENTER">[0,0] </td>
<td BGCOLOR="#FFCCCC">waiting for authentication</td>
</tr>
<tr>
<td ROWSPAN="3" BGCOLOR="#FFCCCC"><p ALIGN="CENTER"><b>waiting for authentication</b> </td>
<td WIDTH="188" ROWSPAN="2" BGCOLOR="#FFCCCC">receive authentication response</td>
<td WIDTH="68" ROWSPAN="2" BGCOLOR="#FFCCCC"><p ALIGN="CENTER">[0,1] </td>
<td ROWSPAN="2" BGCOLOR="#FFCCCC"><p ALIGN="CENTER">check authentication </td>
<td BGCOLOR="#FFCCCC">on success</td>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER">[0,2] </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#FFCCCC">on failure send packet and close connection</td>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER">[0,3] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#FFCCCC">receive other</td>
<td WIDTH="68" BGCOLOR="#FFCCCC"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#FFCCCC">close connection</td>
<td BGCOLOR="#FFCCCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td ROWSPAN="8" BGCOLOR="#CCFFCC"><p ALIGN="CENTER"><b>open</b> </td>
<td WIDTH="188" BGCOLOR="#CCFFCC"> </td>
<td WIDTH="68" BGCOLOR="#CCFFCC"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">send close connection</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,0] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFCC">receive request fragment</td>
<td WIDTH="68" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[1,0] </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC"> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFCC">receive final request fragment</td>
<td WIDTH="68" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[1,1] </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC"> </td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" ROWSPAN="2" BGCOLOR="#CCFFCC">receive function request</td>
<td WIDTH="68" ROWSPAN="2" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[2,0] </td>
<td ROWSPAN="2" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">evaluate function </td>
<td BGCOLOR="#CCFFCC">on success, send response</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[2,1] </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td BGCOLOR="#CCFFCC">on failure, send error message</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[2,2] </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFCC">receive close connection</td>
<td WIDTH="68" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,0] </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">close connection</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,1] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" HEIGHT="21" BGCOLOR="#CCFFCC">receive protocol error</td>
<td WIDTH="68" HEIGHT="21" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,1] </td>
<td HEIGHT="21" COLSPAN="2" BGCOLOR="#CCFFCC">close connection</td>
<td HEIGHT="21" BGCOLOR="#CCFFCC"><p ALIGN="CENTER"> </td>
<td HEIGHT="21" BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFCC">receive other</td>
<td WIDTH="68" BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#CCFFCC">send protocol error, close connection</td>
<td BGCOLOR="#CCFFCC"><p ALIGN="CENTER">[15,1] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td ROWSPAN="12" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"><b>handling request</b> </td>
<td WIDTH="188" BGCOLOR="#CCFFFF"> </td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send response</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,0] </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF"> </td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send log</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,1] </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF"> </td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send warning</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,2] </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF"> </td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send error</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,3] </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF"> </td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send end of response</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[3,4] </td>
<td BGCOLOR="#CCFFCC">open</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF"> </td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send function request</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[2,0] </td>
<td BGCOLOR="#FFFFCC">waiting for function response</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF"> </td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send close connection</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,0] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" ROWSPAN="2" BGCOLOR="#CCFFFF">receive function request</td>
<td WIDTH="68" ROWSPAN="2" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[2,0] </td>
<td ROWSPAN="2" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">evaluate function </td>
<td BGCOLOR="#CCFFFF">on success, send response</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[2,1] </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td BGCOLOR="#CCFFFF">on failure, send error message</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[2,2] </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF">receive close connection</td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,0] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">close connection</td>
<td BGCOLOR="#CCFFFF"> </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF">receive protocol error</td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,1] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">close connection</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#CCFFFF">receive other</td>
<td WIDTH="68" BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#CCFFFF">send protocol error, close connection</td>
<td BGCOLOR="#CCFFFF"><p ALIGN="CENTER">[15,1] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td ROWSPAN="6" BGCOLOR="#FFFFCC"><p ALIGN="CENTER"><b>waiting for function response</b> </td>
<td WIDTH="188" BGCOLOR="#FFFFCC"> </td>
<td WIDTH="68" BGCOLOR="#FFFFCC"> </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC">send close connection</td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[15,0] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#FFFFCC">receive function response</td>
<td WIDTH="68" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[2,1] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC"> </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#FFFFCC">receive function error</td>
<td WIDTH="68" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[2,2] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC"> </td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER"> </td>
<td BGCOLOR="#CCFFFF">handling request</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#FFFFCC">receive close connection</td>
<td WIDTH="68" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[15,0] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC">close connection</td>
<td BGCOLOR="#FFFFCC"> </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#FFFFCC">receive protocol error</td>
<td WIDTH="68" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[15,1] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC">close connection</td>
<td BGCOLOR="#FFFFCC"> </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
<tr>
<td WIDTH="188" BGCOLOR="#FFFFCC">receive other</td>
<td WIDTH="68" BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[x,x] </td>
<td COLSPAN="2" BGCOLOR="#FFFFCC">send protocol error, close connection</td>
<td BGCOLOR="#FFFFCC"><p ALIGN="CENTER">[15,1] </td>
<td BGCOLOR="#FF9999">listening</td>
</tr>
</table>
</center></div>
<h2>Configuration Parameters</h2>
<blockquote>
<h3>Client Side</h3>
<dl>
<dl>
<dl>
<dt><i>authentication</i></dt>
<dd>This setting determines whether authentication is in use on the server. <em>The default
value MUST be to enable authentication.</em> Implementers SHOULD warn administrators to
ensure the client's authentication configuration matches the server's. </dd>
<dt><i>secret file or string</i></dt>
<dd>This must be configured to the same contents as used on the server which will
interoperate with the client. </dd>
</dl>
</dl>
<h3>Server Side</h3>
<dl>
<dl>
<dt><i>authentication</i></dt>
<dd>This setting determines whether authentication is in use on the server. <em>The default
value MUST be to enable authentication.</em> Administrators who choose to disable
authentication SHOULD be warned by the implementer to provide their own security (such as
a firewall or router with filtering) to protect the server from intruders. </dd>
<dt><i>authentication timeout (optional)</i></dt>
<dd>This value is used to configure the time a connection is allowed to take to perform the
authentication handshake.This value may vary depending on network/systems load/performance
and must be carefully chosen to be as little as possible to avoid possible denial of
service attacks. </dd>
<dt><i>secret file or string</i></dt>
<dd>This must be configured to the same contents as used on all clients which will
interoperate with the server. </dd>
<dt><i>challenge string length</i></dt>
<dd>The protocol-enforced minimum challenge length of 5 octets will (with proper pseudo
random number generation) approximate 1 in 1 quadrillion odds of any given challenge being
chosen. For each octet in length added, this minimum figure is multiplied by 256. If
computing power increases at current rates (which has doubled every 18 months for over 30
years, according to Moore's Law), this number will need to be increased at least by one
every 4 years computed from 1998 to maintain wide margins of safety over potential
intruders' computational processing availability. <em>The recommended default is 5 plus
one for every two years since 1998.</em> </dd>
</dl>
</dl>
</dl>
</blockquote>
<h2>References</h2>
<ul>
<li>S. Bradner, <a HREF="ftp://ftp.isi.edu/in-notes/rfc2119.txt" target="_top">"Key words for use in
RFCs to Indicate Requirement Levels", RFC 2119,</a> Harvard University, March 1997 </li>
<li>D. Eastlake, S. Crocker, and J. Schiller, <a HREF="ftp://ftp.isi.edu/in-notes/rfc1750.txt">"Randomness Recommendations for
Security", RFC 1750,</a> IETF Network Working Group, December 1994 </li>
<li>J. Gettys and H. Nielsen, <a HREF="http://www.w3.org/Protocols/MUX/WD-mux-970825.html" target="_top">"Simple
Multiplexing Protocol", W3C Working Draft 25-August-97</a>, World Wide Web Consortium
(W3C), August 1997 </li>
<li>A. Kosut, <a HREF="AJPv1.html">"Apache JServ Protocol", version 1.0</a>, Java
Apache Project, July 1997 </li>
<li>I. Kluft, E. Korthof, S. Mazzocchi, <a HREF="AJPv2.html">"Apache JServ
Protocol", version 2.0</a>, Java Apache Project, February 1998 </li>
<li>R. McCool, <a HREF="http://hoohoo.ncsa.uiuc.edu/cgi/" target="_top">"The Common Gateway
Interface", Version 1.1,</a> National Center for Supercomputing Applications (NCSA),
1994. </li>
<li>R. Rivest <a HREF="ftp://ftp.isi.edu/in-notes/rfc1321.txt" target="_top">"The MD5 Message-Digest
Algorithm", RFC 1321,</a> MIT Laboratory for Computer Science, April 1992 </li>
</ul>
<h2>Contributors</h2>
<table BORDER="1" CELLPADDING="2" CELLSPACING="0" WIDTH="100%">
<tr>
<td colspan="6"><p ALIGN="LEFT">in strict alphabetical order from left to right </td>
</tr>
<tr>
<td><b>Federico Barbieri</b><br>
Brescia, Italy</td>
<td><b>Pierpaolo Fumagalli</b><br>
Erba, Italy</td>
<td><b>Ian Kluft </b><br>
San Jose, California, USA</td>
<td><b>Ed Korthof</b><br>
San Francisco, California, USA</td>
<td><b>Stefano Mazzocchi</b><br>
Pavia, Italy</td>
<td><b>Martin Pool</b><br>
Brisbane, Australia</td>
</tr>
</table>
<h2>Acknowledgements</h2>
<p>This specification was developed through discussion and consensus on the Java Apache
Project's mailing list. The original idea for this model was evolved from ideas proposed
by Ed Korthof, Ian Kluft and Stefano Mazzocchi that were merged into the AJPv2.0 protocol.
Its complexity forced developers to simplify the protocol and innovative ideas and
contributions from people listed above made possible this protocol specification.</p>
<p ALIGN="CENTER"><font SIZE="2">Copyright (c) 1997-98 <a HREF="http://java.apache.org/" target="_top">The
Java Apache Project</a>.<br>
</font><font SIZE="-1">$Id: AJPv21.html,v 1.3 1999/06/09 05:21:29 jonbolt Exp $</font><font SIZE="2"><br>
All rights reserved.</font></p>
</body>
</html>
|
