summaryrefslogtreecommitdiffstats
path: root/rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer
diff options
context:
space:
mode:
authorhongbotian <hongbo.tianhongbo@huawei.com>2015-11-30 03:10:21 -0500
committerhongbotian <hongbo.tianhongbo@huawei.com>2015-11-30 03:10:21 -0500
commitc0b7206652b2852bc574694e7ba07ba1c2acdc00 (patch)
tree5cb95cb0e19e03610525903df46279df2c3b7eb1 /rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer
parentb6d3d6e668b793220f2d3af1bc3e828553dc3fe6 (diff)
delete app
Change-Id: Id4c572809969ebe89e946e88063eaed262cff3f2 Signed-off-by: hongbotian <hongbo.tianhongbo@huawei.com>
Diffstat (limited to 'rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer')
-rw-r--r--rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13a.html653
-rw-r--r--rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13ext.html653
2 files changed, 0 insertions, 1306 deletions
diff --git a/rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13a.html b/rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13a.html
deleted file mode 100644
index 53cf10a9..00000000
--- a/rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13a.html
+++ /dev/null
@@ -1,653 +0,0 @@
-<html><head><META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>The Apache Tomcat Connector - AJP Protocol Reference - AJPv13</title><meta name="author" value="danmil@shore.net"><meta name="email" value="danmil@shore.net"><meta name="author" value="Jean-Frederic Clere"><meta name="email" value="jfrederic.clere@fujitsu-siemens.com"><link href="../../style.css" type="text/css" rel="stylesheet"></head><body bgcolor="#ffffff" text="#000000" link="#525D76" alink="#525D76" vlink="#525D76"><table border="0" width="100%" cellspacing="4"><!--PAGE HEADER--><tr><td colspan="2"><!--TOMCAT LOGO--><a href="http://tomcat.apache.org/"><img src="../../images/tomcat.gif" align="left" alt="Apache Tomcat" border="0"></a><!--APACHE LOGO--><a href="http://www.apache.org/"><img src="http://www.apache.org/images/asf-logo.gif" align="right" alt="Apache Logo" border="0"></a></td></tr><!--HEADER SEPARATOR--><tr><td colspan="2"><hr noshade size="1"></td></tr><tr><!--RIGHT SIDE MAIN BODY--><td width="80%" valign="top" align="left"><table border="0" width="100%" cellspacing="4"><tr><td align="left" valign="top"><h1>The Apache Tomcat Connector - AJP Protocol Reference</h1><h2>AJPv13</h2></td><td align="right" valign="top" nowrap="true"><img src="../../images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Intro"><strong>Intro</strong></a></font></td></tr><tr><td><blockquote>
-
-<p>
-The original document was written by
-Dan Milstein, <author email="danmil@shore.net">danmil@shore.net</author>
-on December 2000. The present document is generated out of an xml file
-to allow a more easy integration in the Tomcat documentation.
-
-</p>
-
-<p>
-This describes the Apache JServ Protocol version 1.3 (hereafter
-<b>ajp13</b>). There is, apparently, no current documentation of how the
-protocol works. This document is an attempt to remedy that, in order to
-make life easier for maintainers of JK, and for anyone who wants to
-port the protocol somewhere (into jakarta 4.x, for example).
-</p>
-
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="author"><strong>author</strong></a></font></td></tr><tr><td><blockquote>
-
-<p>
-I am not one of the designers of this protocol -- I believe that Gal
-Shachor was the original designer. Everything in this document is derived
-from the actual implementation I found in the tomcat 3.x code. I hope it
-is useful, but I can't make any grand claims to perfect accuracy. I also
-don't know why certain design decisions were made. Where I was able, I've
-offered some possible justifications for certain choices, but those are
-only my guesses. In general, the C code which Shachor wrote is very clean
-and comprehensible (if almost totally undocumented). I've cleaned up the
-Java code, and I think it's reasonably readable.
-</p>
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Design Goals"><strong>Design Goals</strong></a></font></td></tr><tr><td><blockquote>
-
-<p>
-According to email from Gal Shachor to the jakarta-dev mailing list,
-the original goals of <b>JK</b> (and thus <b>ajp13</b>) were to extend
-<b>mod_jserv</b> and <b>ajp12</b> by (I am only including the goals which
-relate to communication between the web server and the servlet container):
-
-<ul>
- <li> Increasing performance (speed, specifically). </li>
-
- <li> Adding support for SSL, so that <b class="code">isSecure()</b> and
- <b class="code">getScheme()</b> will function correctly within the servlet
- container. The client certificates and cipher suite will be
- available to servlets as request attributes. </li>
-
-</ul>
-</p>
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Overview of the protocol"><strong>Overview of the protocol</strong></a></font></td></tr><tr><td><blockquote>
-
-<p>
-The <b>ajp13</b> protocol is packet-oriented. A binary format was
-presumably chosen over the more readable plain text for reasons of
-performance. The web server communicates with the servlet container over
-TCP connections. To cut down on the expensive process of socket creation,
-the web server will attempt to maintain persistent TCP connections to the
-servlet container, and to reuse a connection for multiple request/response
-cycles.
-</p><p>
-Once a connection is assigned to a particular request, it will not be
-used for any others until the request-handling cycle has terminated. In
-other words, requests are not multiplexed over connections. This makes
-for much simpler code at either end of the connection, although it does
-cause more connections to be open at once.
-</p><p>
-Once the web server has opened a connection to the servlet container,
-the connection can be in one of the following states:
-</p><p>
-<ul>
- <li> Idle <br> No request is being handled over this connection. </li>
- <li> Assigned <br> The connecton is handling a specific request.</li>
-</ul>
-
-</p><p>
-Once a connection is assigned to handle a particular request, the basic
-request informaton (e.g. HTTP headers, etc) is sent over the connection in
-a highly condensed form (e.g. common strings are encoded as integers).
-Details of that format are below in Request Packet Structure. If there is a
-body to the request (content-length &gt; 0), that is sent in a separate
-packet immediately after.
-</p><p>
-At this point, the servlet container is presumably ready to start
-processing the request. As it does so, it can send the
-following messages back to the web server:
-
-<ul>
- <li>SEND_HEADERS <br>Send a set of headers back to the browser.</li>
-
- <li>SEND_BODY_CHUNK <br>Send a chunk of body data back to the browser.</li>
-
- <li>GET_BODY_CHUNK <br>Get further data from the request if it hasn't all
- been transferred yet. This is necessary because the packets have a fixed
- maximum size and arbitrary amounts of data can be included the body of a
- request (for uploaded files, for example). (Note: this is unrelated to
- HTTP chunked tranfer).</li>
-
- <li>END_RESPONSE <br> Finish the request-handling cycle.</li>
-</ul>
-</p><p>
-
-Each message is accompanied by a differently formatted packet of data. See
-Response Packet Structures below for details.
-</p>
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Basic Packet Structure"><strong>Basic Packet Structure</strong></a></font></td></tr><tr><td><blockquote>
-
-<p>
-There is a bit of an XDR heritage to this protocol, but it differs in
-lots of ways (no 4 byte alignment, for example).
-</p><p>
-Byte order: I am not clear about the endian-ness of the individual
-bytes. I'm guessing the bytes are little-endian, because that's what XDR
-specifies, and I'm guessing that sys/socket library is magically making
-that so (on the C side). If anyone with a better knowledge of socket calls
-can step in, that would be great.
-</p><p>
-There are four data types in the protocol: bytes, booleans, integers and
-strings.
-
-<dl>
- <dt><b>Byte</b></dt>
- <dd>A single byte.</dd>
-
- <dt><b>Boolean</b></dt>
- <dd>A single byte, 1 = true, 0 = false. Using other non-zero values as
- true (i.e. C-style) may work in some places, but it won't in
- others.</dd>
-
- <dt><b>Integer</b></dt>
- <dd>A number in the range of 0 to 2^16 (32768). Stored in 2 bytes with
- the high-order byte first.</dd>
-
- <dt><b>String</b></dt>
- <dd>A variable-sized string (length bounded by 2^16). Encoded with the
- length packed into two bytes first, followed by the string (including the
- terminating '\0'). Note that the encoded length does <b>not</b> include
- the trailing '\0' -- it is like <b class="code">strlen</b>. This is a touch
- confusing on the Java side, which is littered with odd autoincrement
- statements to skip over these terminators. I believe the reason this was
- done was to allow the C code to be extra efficient when reading strings
- which the servlet container is sending back -- with the terminating \0
- character, the C code can pass around references into a single buffer,
- without copying. If the \0 was missing, the C code would have to copy
- things out in order to get its notion of a string. Note a size of -1
- (65535) indicates a null string and no data follow the length in this
- case.</dd>
-</dl>
-</p>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Packet Size"><strong>Packet Size</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-According to much of the code, the max packet
-size is 8 * 1024 bytes (8K). The actual length of the packet is encoded in the
-header.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Packet Headers"><strong>Packet Headers</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-Packets sent from the server to the container begin with
-<b class="code">0x1234</b>. Packets sent from the container to the server begin
-with <b class="code">AB</b> (that's the ASCII code for A followed by the ASCII
-code for B). After those first two bytes, there is an integer (encoded as
-above) with the length of the payload. Although this might suggest that
-the maximum payload could be as large as 2^16, in fact, the code sets the
-maximum to be 8K.
-
-
-<table>
- <tr>
- <th colspan="6">Packet Format (Server-&gt;Container)</th>
- </tr>
-
- <tr>
- <th>Byte</th>
- <td>0</td>
- <td>1</td>
- <td>2</td>
- <td>3</td>
- <td>4...(n+3)</td>
- </tr>
-
- <tr>
- <th>Contents</th>
- <td>0x12</td>
- <td>0x34</td>
- <td colspan="2">Data Length (n)</td>
- <td>Data</td>
- </tr>
-</table>
-
-<table>
- <tr>
- <th colspan="6"><b>Packet Format (Container-&gt;Server)</b></th>
- </tr>
-
- <tr>
- <th>Byte</th>
- <td>0</td>
- <td>1</td>
- <td>2</td>
- <td>3</td>
- <td>4...(n+3)</td>
- </tr>
-
- <tr>
- <th>Contents</th>
- <td>A</td>
- <td>B</td>
- <td colspan="2">Data Length (n)</td>
- <td>Data</td>
- </tr>
-</table>
-</p>
-<p>
-<A NAME="prefix-codes"></A> For most packets, the first byte of the
-payload encodes the type of message. The exception is for request body
-packets sent from the server to the container -- they are sent with a
-standard packet header (0x1234 and then length of the packet), but without
-any prefix code after that (this seems like a mistake to me).
-</p><p>
-The web server can send the following messages to the servlet container:
-
-<table>
- <tr>
- <th>Code</th>
- <th>Type of Packet</th>
- <th>Meaning</th>
- </tr>
- <tr>
- <td>2</td>
- <td>Forward Request</td>
- <td>Begin the request-processing cycle with the following data</td>
- </tr>
- <tr>
- <td>7</td>
- <td>Shutdown</td>
- <td>The web server asks the container to shut itself down.</td>
- </tr>
- <tr>
- <td>8</td>
- <td>Ping</td>
- <td>The web server asks the container to take control (secure login phase).</td>
- </tr>
- <tr>
- <td>10</td>
- <td>CPing</td>
- <td>The web server asks the container to respond quickly with a CPong.</td>
- </tr>
- <tr>
- <td>none</td>
- <td>Data</td>
- <td>Size (2 bytes) and corresponding body data.</td>
- </tr>
-</table>
-</p>
-<p>
-To ensure some
-basic security, the container will only actually do the <b class="code">Shutdown</b> if the
-request comes from the same machine on which it's hosted.
-</p>
-<p>
-The first <b class="code">Data</b> packet is send immediatly after the <b class="code">Forward Request</b> by the web server.
-</p>
-
-<p>The servlet container can send the following types of messages to the web
-server:
-<table>
- <tr>
- <th>Code</th>
- <th>Type of Packet</th>
- <th>Meaning</th>
- </tr>
- <tr>
- <td>3</td>
- <td>Send Body Chunk</td>
- <td>Send a chunk of the body from the servlet container to the web
- server (and presumably, onto the browser). </td>
- </tr>
- <tr>
- <td>4</td>
- <td>Send Headers</td>
- <td>Send the response headers from the servlet container to the web
- server (and presumably, onto the browser).</td>
- </tr>
- <tr>
- <td>5</td>
- <td>End Response</td>
- <td>Marks the end of the response (and thus the request-handling cycle).</td>
- </tr>
- <tr>
- <td>6</td>
- <td>Get Body Chunk</td>
- <td>Get further data from the request if it hasn't all been transferred
- yet.</td>
- </tr>
- <tr>
- <td>9</td>
- <td>CPong Reply</td>
- <td>The reply to a CPing request</td>
- </tr>
-</table>
-</p>
-<p>
-Each of the above messages has a different internal structure, detailed below.
-</p>
-</blockquote></td></tr></table>
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Request Packet Structure"><strong>Request Packet Structure</strong></a></font></td></tr><tr><td><blockquote>
-
-<p>
-For messages from the server to the container of type "Forward Request":
-</p><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><p>
-The <b class="code">request_headers</b> have the following structure:
-</p><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><p>
-
-The <b class="code">attributes</b> are optional and have the following structure:
-</p><p>
-<div class="example"><pre>
-attribute_name := sc_a_name | (sc_a_req_attribute string)
-
-attribute_value := (string)
-
-</pre></div>
-</p><p>
-Not that the all-important header is "content-length', because it
-determines whether or not the container looks for another packet
-immediately.
-</p><p>
-Detailed description of the elements of Forward Request.
-</p>
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="request_prefix"><strong>request_prefix</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-For all requests, this will be 2.
-See above for details on other <A HREF="#prefix-codes">prefix codes</A>.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="method"><strong>method</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-The HTTP method, encoded as a single byte:
-</p>
-
-<p>
-<table>
- <tr><th>Command Name</th><th>Code</th></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>
-
-<p>Later version of ajp13, when used with mod_jk2, will transport
-additional methods, even if they are not in this list.
-</p>
-
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="protocol, req_uri, remote_addr, remote_host, server_name, server_port, is_ssl"><strong>protocol, req_uri, remote_addr, remote_host, server_name, server_port, is_ssl</strong></a></font></td></tr><tr><td><blockquote>
-<p>
- These are all fairly self-explanatory. Each of these is required, and
- will be sent for every request.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Headers"><strong>Headers</strong></a></font></td></tr><tr><td><blockquote>
-<p>
- The structure of <b class="code">request_headers</b> is the following:
- First, the number of headers <b class="code">num_headers</b> is encoded.
- Then, a series of header name <b class="code">req_header_name</b> / value
- <b class="code">req_header_value</b> pairs follows.
- Common header names are encoded as integers,
- to save space. If the header name is not in the list of basic headers,
- it is encoded normally (as a string, with prefixed length). The list of
- common headers <b class="code">sc_req_header_name</b>and their codes
- is as follows (all are case-sensitive):
-</p><p>
-<table>
- <tr><th>Name</th><th>Code value</th><th>Code name</th></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><p>
- The Java code that reads this grabs the first two-byte integer and if
- it sees an <b class="code">'0xA0'</b> in the most significant
- byte, it uses the integer in the second byte as an index into an array of
- header names. If the first byte is not '0xA0', it assumes that the
- two-byte integer is the length of a string, which is then read in.
-</p><p>
- This works on the assumption that no header names will have length
- greater than 0x9999 (==0xA000 - 1), which is perfectly reasonable, though
- somewhat arbitrary. (If you, like me, started to think about the cookie
- spec here, and about how long headers can get, fear not -- this limit is
- on header <b>names</b> not header <b>values</b>. It seems unlikely that
- unmanageably huge header names will be showing up in the HTTP spec any time
- soon).
-</p><p>
- <b>Note:</b> The <b class="code">content-length</b> header is extremely
- important. If it is present and non-zero, the container assumes that
- the request has a body (a POST request, for example), and immediately
- reads a separate packet off the input stream to get that body.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Attributes"><strong>Attributes</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-
- The attributes prefixed with a <b class="code">?</b>
- (e.g. <b class="code">?context</b>) are all optional. For each, there is a
- single byte code to indicate the type of attribute, and then a string to
- give its value. They can be sent in any order (thogh the C code always
- sends them in the order listed below). A special terminating code is
- sent to signal the end of the list of optional attributes. The list of
- byte codes is:
-</p><p>
-
-<table>
- <tr><th>Information</th><th>Code Value</th><th>Note</th></tr>
- <tr><td>?context</td><td>0x01</td><td>Not currently implemented</td></tr>
- <tr><td>?servlet_path</td><td>0x02</td><td>Not currently implemented</td></tr>
- <tr><td>?remote_user</td><td>0x03</td><td></td></tr>
- <tr><td>?auth_type</td><td>0x04</td><td></td></tr>
- <tr><td>?query_string</td><td>0x05</td><td></td></tr>
- <tr><td>?route</td><td>0x06</td><td></td></tr>
- <tr><td>?ssl_cert</td><td>0x07</td><td></td></tr>
- <tr><td>?ssl_cipher</td><td>0x08</td><td></td></tr>
- <tr><td>?ssl_session</td><td>0x09</td><td></td></tr>
- <tr><td>?req_attribute</td><td>0x0A</td><td>Name (the name of the attribut follows)</td></tr>
- <tr><td>?ssl_key_size</td><td>0x0B</td><td></td></tr>
- <tr><td>?secret</td><td>0x0C</td><td></td></tr>
- <tr><td>?stored_method</td><td>0x0D</td><td></td></tr>
- <tr><td>are_done</td><td>0xFF</td><td>request_terminator</td></tr>
-</table>
-
-</p><p>
-
- The <b class="code">context</b> and <b class="code">servlet_path</b> are not currently
- set by the C code, and most of the Java code completely ignores whatever
- is sent over for those fields (and some of it will actually break if a
- string is sent along after one of those codes). I don't know if this is
- a bug or an unimplemented feature or just vestigial code, but it's
- missing from both sides of the connection.
-</p><p>
- The <b class="code">remote_user</b> and <b class="code">auth_type</b> presumably refer
- to HTTP-level authentication, and communicate the remote user's username
- and the type of authentication used to establish their identity (e.g. Basic,
- Digest). I'm not clear on why the password isn't also sent, but I don't
- know HTTP authentication inside and out.
-</p><p>
- The <b class="code">query_string</b>, <b class="code">ssl_cert</b>,
- <b class="code">ssl_cipher</b>, and <b class="code">ssl_session</b> refer to the
- corresponding pieces of HTTP and HTTPS.
-</p><p>
- The <b class="code">route</b>, as I understand it, is used to support sticky
- sessions -- associating a user's sesson with a particular Tomcat instance
- in the presence of multiple, load-balancing servers. I don't know the
- details.
-</p><p>
- Beyond this list of basic attributes, any number of other attributes can
- be sent via the <b class="code">req_attribute</b> code (0x0A). A pair of strings
- to represent the attribute name and value are sent immediately after each
- instance of that code. Environment values are passed in via this method.
-</p><p>
- Finally, after all the attributes have been sent, the attribute terminator,
- 0xFF, is sent. This signals both the end of the list of attributes and
- also then end of the Request Packet.
-</p>
-</blockquote></td></tr></table>
-
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Response Packet Structure"><strong>Response Packet Structure</strong></a></font></td></tr><tr><td><blockquote>
-
-<p>
-For messages which the container can send back to the server.
-
-<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>
-
-</p>
-<p>
-Details:
-</p>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Send Body Chunk"><strong>Send Body Chunk</strong></a></font></td></tr><tr><td><blockquote>
-<p>
- The chunk is basically binary data, and is sent directly back to the browser.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Send Headers"><strong>Send Headers</strong></a></font></td></tr><tr><td><blockquote>
-<p>
- The status code and message are the usual HTTP things (e.g. "200" and "OK").
- The response header names are encoded the same way the request header names are.
- See <A HREF="#header_encoding">above</A> for details about how the the
- codes are distinguished from the strings. The codes for common headers are:
-</p>
-
-<p>
-<table>
- <tr><th>Name</th><th>Code value</th></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>
- After the code or the string header name, the header value is immediately
- encoded.
-</p>
-
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="End Response"><strong>End Response</strong></a></font></td></tr><tr><td><blockquote>
-<p>
- Signals the end of this request-handling cycle. If the
- <b class="code">reuse</b> flag is true (==1), this TCP connection can now be used to
- handle new incoming requests. If <b class="code">reuse</b> is false (anything
- other than 1 in the actual C code), the connection should be closed.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Get Body Chunk"><strong>Get Body Chunk</strong></a></font></td></tr><tr><td><blockquote>
-<p>
- The container asks for more data from the request (If the body was
- too large to fit in the first packet sent over or when the request is
- chuncked).
- The server will send a body packet back with an amount of data which is
- the minimum of the <b class="code">request_length</b>,
- the maximum send body size (8186 (8 Kbytes - 6)), and the
- number of bytes actually left to send from the request body.
-<br>
- If there is no more data in the body (i.e. the servlet container is
- trying to read past the end of the body), the server will send back an
- "empty" packet, which is a body packet with a payload length of 0.
- (0x12,0x34,0x00,0x00)
-</p>
-</blockquote></td></tr></table>
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Questions I Have"><strong>Questions I Have</strong></a></font></td></tr><tr><td><blockquote>
-
-<p> What happens if the request headers &gt; max packet size? There is no
-provision to send a second packet of request headers in case there are more
-than 8K (I think this is correctly handled for response headers, though I'm
-not certain). I don't know if there is a way to get more than 8K worth of
-data into that initial set of request headers, but I'll bet there is
-(combine long cookies with long ssl information and a lot of environment
-variables, and you should hit 8K easily). I think the connector would just
-fail before trying to send any headers in this case, but I'm not certain.</p>
-
-<p> What about authentication? There doesn't seem to be any authentication
-of the connection between the web server and the container. This strikes
-me as potentially dangerous.</p>
-
-</blockquote></td></tr></table></td></tr><!--FOOTER SEPARATOR--><tr><td colspan="2"><hr noshade size="1"></td></tr><!--PAGE FOOTER--><tr><td colspan="2"><div align="center"><font color="#525D76" size="-1"><em>
- Copyright &copy; 1999-2011, Apache Software Foundation
- </em></font></div></td></tr></table></body></html> \ No newline at end of file
diff --git a/rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13ext.html b/rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13ext.html
deleted file mode 100644
index 300f4b3c..00000000
--- a/rubbos/app/tomcat-connectors-1.2.32-src/docs/ajp/printer/ajpv13ext.html
+++ /dev/null
@@ -1,653 +0,0 @@
-<html><head><META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>The Apache Tomcat Connector - AJP Protocol Reference - AJPv13 extensions Proposal</title><meta name="author" value="Henri Gomez"><meta name="email" value="hgomez@apache.org"><link href="../../style.css" type="text/css" rel="stylesheet"></head><body bgcolor="#ffffff" text="#000000" link="#525D76" alink="#525D76" vlink="#525D76"><table border="0" width="100%" cellspacing="4"><!--PAGE HEADER--><tr><td colspan="2"><!--TOMCAT LOGO--><a href="http://tomcat.apache.org/"><img src="../../images/tomcat.gif" align="left" alt="Apache Tomcat" border="0"></a><!--APACHE LOGO--><a href="http://www.apache.org/"><img src="http://www.apache.org/images/asf-logo.gif" align="right" alt="Apache Logo" border="0"></a></td></tr><!--HEADER SEPARATOR--><tr><td colspan="2"><hr noshade size="1"></td></tr><tr><!--RIGHT SIDE MAIN BODY--><td width="80%" valign="top" align="left"><table border="0" width="100%" cellspacing="4"><tr><td align="left" valign="top"><h1>The Apache Tomcat Connector - AJP Protocol Reference</h1><h2>AJPv13 extensions Proposal</h2></td><td align="right" valign="top" nowrap="true"><img src="../../images/void.gif" width="1" height="1" vspace="0" hspace="0" border="0"></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Introduction"><strong>Introduction</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-This document is a proposal of evolution of the current
-Apache JServ Protocol version 1.3, also known as ajp13.
-I'll not cover here the full protocol but only the add-on from ajp13.
-
-This nth pass include comments from the tomcat-dev list and
-misses discovered during developpment.
-</p>
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Missing features in AJP13"><strong>Missing features in AJP13</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-ajp13 is a good protocol to link a servlet engine like tomcat to a web server like Apache:
-
-<ul>
-<li>
-use persistants connections to avoid reconnect time at each request
-</li>
-<li>
-encode many http commands to reduce stream size
-</li>
-<li>
-send to servlet engine many info from web server (like SSL certs)
-</li>
-</ul>
-<p>
-But ajp13 lacks support for :
-</p>
-<ul>
-<li>
- security between web server and servlet engine.
- Anybody can connect to an ajp13 port (no login mecanism used)
- You could connect, for example with telnet, and keep the remote thread
- up by not sending any data (no timeout in connection)
-</li>
-<li>
- context information passed from servlet engine to web server.
- Part of the configuration of JK, the web server connector, is to
- indicate to the web server which URI to handle.
- The mod_jk JkMount directive, told to web server which URI must be
- forwarded to servlet engine.
- A servlet engine allready knows which URI it handle and TC 3.3 is
- allready capable to generate a config file for JK from the list
- of available contexts.
-</li>
-<li>
- state update of contexts from servlet engine to web server.
- Big site with farm of Tomcat, like ISP and virtuals hosters,
- may need to stop a context for admin purposes. In that case the front
- web server must know that the context is currently down, to eventually
- relay the request to another Tomcat
-</li>
-<li>
- verify state of connection before sending request.
- Actually JK send the request to the servlet engine and next wait
- for the answer. But one of the beauty of the socket API, is you that
- you could write() to a closed connection without any error reporting,
- but a read() to a closed connection return you the error code.
-</li>
-</ul>
-
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Proposed add-ons to AJP13"><strong>Proposed add-ons to AJP13</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-Let's descrive here the features and add-on that could be added to AJP13.
-Since this document is a proposal, a reasonable level of chaos must be expected at first.
-Be sure that discussion on tomcat list will help clarify points, add
-features but the current list seems to be a 'minimun vital'
-
-<ul>
-
-<li>
-Advanced login features at connect time
-</li>
-
-<li>
-Basic authorisation system, where a shared secret key is
-present in web server and servlet engine.
-</li>
-
-<li>
-Basic protocol negociation, just to be sure that if functionnalities are added
-to AJP13 in the future, current implementations will still works.
-</li>
-
-<li>
-Clean handling of 'Unknown packets'
-</li>
-
-<li>
-Extended env vars passed from web-server to servlet engine.
-</li>
-
-<li>
-Add extra SSL informations needed by Servlet 2.3 API (like SSL_KEY_SIZE)
-</li>
-
-</ul>
-
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Advanced login"><strong>Advanced login</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-
-<ol>
-<li>
-WEB-SERVER send LOGIN INIT CMD + NEGOCIATION DATA + WEB SERVER INFO
-</li>
-<li>
- TOMCAT respond with LOGIN SEED CMD + RANDOM DATA
-</li>
-<li>
- WEB-SERVER calculted the MD5 of RANDOM DATA+SECRET DATA
-</li>
-<li>
- WEB-SERVER send LOGIN COMP CMD + MD5 (SECRET DATA + RANDOM DATA)
-</li>
-<li>
- TOMCAT respond with LOGIN STATUS CMD + NEGOCIED DATA + SERVLET ENGINE INFO
-</li>
-</ol>
-
-To prevent DOS attack, the servlet engine will wait
-the LOGIN CMD only 15/30 seconds and reports the
-timeout exception for admins investigation.
-
-The login command will contains basic protocol
-negociation information like compressing ability,
-crypto, context info (at start up), context update at
-run-time (up/down), level of SSL env vars, AJP protocol
-level supported (level1/level2/level3...)
-
-The Web server info will contain web server info and
-connector name (ie Apache 1.3.26 + mod_ssl 2.8.8 + mod_jk 1.2.1 + mod_perl 1.25).
-
-The servlet engine will mask the negociation mask with it's own
-mask (what it can do) and return it when loggin is accepted.
-
-This will help having a basic AJP13 implementation (level 1)
-on a web-server working with a more advanced protocol handler on
-the servlet engine side or vice-versa.
-
-AJP13 was designed to be small and fast and so many
-SSL informations present in the web-server are not
-forwarded to the servlet engine.
-
-We add here four negociations flags to provide more
-informations on client SSL data (certs), server SSL datas,
-crypto used, and misc datas (timeout...).
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Messages Stream"><strong>Messages Stream</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-<div class="example"><pre>
-+----------------+------------------+-----------------+
-| LOGIN INIT CMD | NEGOCIATION DATA | WEB SERVER INFO |
-+----------------+------------------+-----------------+
-
-+----------------+----------------+
-| LOGIN SEED CMD | MD5 of entropy |
-+----------------+----------------+
-
-+----------------+----------------------------+
-| LOGIN COMP CMD | MD5 of RANDOM + SECRET KEY |
-+----------------+----------------------------+
-
-+-----------+---------------+---------------------+
-| LOGOK CMD | NEGOCIED DATA | SERVLET ENGINE INFO |
-+-----------+---------------+---------------------+
-
-+------------+--------------+
-| LOGNOK CMD | FAILURE CODE |
-+------------+--------------+
-</pre></div>
-
-<ul>
-<li>
-LOGIN INIT CMD, LOGIN SEED CMD, LOGIN COMP CMD, LOGOK CMD, LOGNOK CMD are 1 byte long.
-</li>
-<li>
-MD5, MD5 of RANDOM + SECRET KEY are 32 chars long.
-</li>
-<li>
-NEGOCIATION DATA, NEGOCIED DATA, FAILURE CODE are 32 bits long.
-</li>
-<li>
-WEB SERVER INFO, SERVLET ENGINE INFO are CString.
-</li>
-</ul>
-
-The secret key will be set by a new propertie in
-workers.properties : secretkey
-<div class="example"><pre>
-worker.ajp13.port=8009
-worker.ajp13.host=localhost
-worker.ajp13.type=ajp13
-worker.ajp13.secretkey=myverysecretkey
-</pre></div>
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Shutdown feature"><strong>Shutdown feature</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-AJP13 miss a functionnality of AJP12, which is shutdown command.
-A logout will tell servlet engine to shutdown itself.
-<div class="example"><pre>
-+--------------+----------------------------+
-| SHUTDOWN CMD | MD5 of RANDOM + SECRET KEY |
-+--------------+----------------------------+
-
-+------------+
-| SHUTOK CMD |
-+------------+
-
-+-------------+--------------+
-| SHUTNOK CMD | FAILURE CODE |
-+-------------+--------------+
-</pre></div>
-
-<ul>
-<li>
-SHUTDOWN CMD, SHUTOK CMD, SHUTNOK CMD are 1 byte long.
-</li>
-<li>
-MD5 of RANDOM + SECRET KEY are 32 chars long.
-</li>
-<li>
-FAILURE CODE is 32 bits long.
-</li>
-</ul>
-
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Extended Env Vars feature"><strong>Extended Env Vars feature</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-NOTA:
-
-While working on AJP13 in JK, I really discovered "JkEnvVar".
-The following "Extended Env Vars feature" description may not
-be implemented in extended AJP13 since allready available in original
-implementation.
-
-DESC:
-
-Many users will want to see some of their web-server env vars
-passed to their servlet engine.
-
-To reduce the network traffic, the web-servlet will send a
-table to describing the external vars in a shorter fashion.
-
-We'll use there a functionnality allready present in AJP13,
-attributes list :
-
-In the AJP13, we've got :
-
-<div class="example"><pre>
-AJP13_FORWARD_REQUEST :=
- prefix_code 2
- 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)
-
- ?context (byte string)
- ?servlet_path (byte string)
- ?remote_user (byte string)
- ?auth_type (byte string)
- ?query_string (byte string)
- ?route (byte string)
- ?ssl_cert (byte string)
- ?ssl_cipher (byte string)
- ?ssl_session (byte string)
-
- ?attributes *(attribute_name attribute_value)
- request_terminator (byte)
-</pre></div>
-
-Using short 'web server attribute name' will reduce the
-network traffic.
-
-<div class="example"><pre>
-+-------------------+---------------------------+-------------------------------+----+
-| EXTENDED VARS CMD | WEB SERVER ATTRIBUTE NAME | SERVLET ENGINE ATTRIBUTE NAME | ES |
-+-------------------+---------------------------+-------------------------------+----+
-</pre></div>
-
-ie :
-
-<div class="example"><pre>
-JkExtVars S1 SSL_CLIENT_V_START javax.servlet.request.ssl_start_cert_date
-JkExtVars S2 SSL_CLIENT_V_END javax.servlet.request.ssl_end_cert_date
-JkExtVars S3 SSL_SESSION_ID javax.servlet.request.ssl_session_id
-
-
-+-------------------+----+-------------------------------------------+
-| EXTENDED VARS CMD | S1 | javax.servlet.request.ssl_start_cert_date |
-+-------------------+----+-------------------------------------------+
-+----+-----------------------------------------+
-| S2 | javax.servlet.request.ssl_end_cert_date |
-+----+-----------------------------------------+
-+----+-----------------------------------------+
-| S3 | javax.servlet.request.ssl_end_cert_date |
-+----+-----------------------------------------+
-</pre></div>
-
-During transmission in extended AJP13 we'll see attributes name
-containing S1, S2, S3 and attributes values of
-2001/01/03, 2002/01/03, 0123AFE56.
-
-This example showed the use of extended SSL vars but
-any 'personnal' web-server vars like custom authentification
-vars could be reused in the servlet engine.
-The cost will be only some more bytes in the AJP traffic.
-
-<ul>
-<li>
-EXTENDED VARS CMD is 1 byte long.
-</li>
-<li>
-WEB SERVER ATTRIBUTE NAME, SERVLET ENGINE ATTRIBUTE NAME are CString.
-</li>
-<li>
-ES is an empty CString.
-</li>
-</ul>
-
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Context informations forwarding for Servlet engine to Web Server"><strong>Context informations forwarding for Servlet engine to Web Server</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-Just after the LOGON PHASE, the web server will ask for the list of contexts
-and URLs/URIs handled by the servlet engine.
-It will ease installation in many sites, reduce questions about configuration
-on tomcat-user list, and be ready for servlet API 2.3.
-
-This mode will be activated by a new directive JkAutoMount
-
-ie: JkAutoMount examples myworker1 /examples/
-
-If we want to get ALL the contexts handled by the servlet engine, willcard
-could be used :
-
-ie: JkAutoMount * myworker1 *
-
-A servlet engine could have many contexts, /examples, /admin, /test.
-We may want to use only some contexts for a given worker. It was
-done previously, in apache HTTP server for example, by setting by
-hand the JkMount accordingly in each [virtual] area of Apache.
-
-If you web-server support virtual hosting, we'll forward also that
-information to servlet engine which will only return contexts for
-that virtual host.
-In that case the servlet engine will only return the URL/URI matching
-these particular virtual server (defined in server.xml).
-This feature will help ISP and big sites which mutualize large farm
-of Tomcat in load-balancing configuration.
-
-<div class="example"><pre>
-+-----------------+-------------------+----------+----------+----+
-| CONTEXT QRY CMD | VIRTUAL HOST NAME | CONTEXTA | CONTEXTB | ES |
-+-----------------+-------------------+----------+----------+----+
-
-+------------------+-------------------+----------+-------------------+----------+---------------+----+
-| CONTEXT INFO CMD | VIRTUAL HOST NAME | CONTEXTA | URL1 URL2 URL3 ES | CONTEXTB | URL1 URL2 ... | ES |
-+------------------+-------------------+----------+-------------------+----------+---------------+----+
-</pre></div>
-
-We'll discover via context-query, the list of URL/MIMES handled by the remove servlet engine
-for a list of contextes.
-In wildcard mode, CONTEXTA will contains just '*'.
-
-<ul>
-<li>
-CONTEXT QRY CMD and CONTEXT INFO CMD are 1 byte long.
-</li>
-<li>
-VIRTUAL HOST NAME is a CString, ie an array of chars terminated by a null byte (/0).
-</li>
-<li>
-An empty string is just a null byte (/0).
-</li>
-<li>
-ES is an empty CString. Indicate end of URI/URLs or end of CONTEXTs.
-</li>
-</ul>
-
-NB:<br>
-When VirtualMode is not to be used, the VIRTUAL HOST NAME is '*'.
-In that case the servlet engine will send all contexts handled.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Context informations updates from Servlet engine to Web Server"><strong>Context informations updates from Servlet engine to Web Server</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-Context update are messages caming from the servlet engine each time a context
-is desactivated/reactivated. The update will be in use when the directive JkUpdateMount.
-This directive will set the AJP13_CONTEXT_UPDATE_NEG flag.
-
-ie: JkUpdateMount myworker1
-
-<div class="example"><pre>
-+--------------------+-------------------+----------+--------+----------+--------+----+
-| CONTEXT UPDATE CMD | VIRTUAL HOST NAME | CONTEXTA | STATUS | CONTEXTB | STATUS | ES |
-+--------------------+-------------------+----------+--------+----------+--------+----+
-</pre></div>
-
-<ul>
-<li>
-CONTEXT UPDATE CMD, STATUS are 1 byte long.
-</li>
-<li>
-VIRTUAL HOST NAME, CONTEXTS are CString.
-</li>
-<li>
-ES is an empty CString. Indicate end of CONTEXTs.
-</li>
-</ul>
-
-NB:<br>
-When VirtualMode is not in use, the VIRTUAL HOST NAME is '*'.
-STATUS is one byte indicating if context is UP/DOWN/INVALID
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Context status query to Servlet engine"><strong>Context status query to Servlet engine</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-This query will be used by the web-server to determine if a given
-contexts are UP, DOWN or INVALID (and should be removed).
-
-<div class="example"><pre>
-+-------------------+--------------------+----------+----------+----+
-| CONTEXT STATE CMD | VIRTUAL HOST NAME | CONTEXTA | CONTEXTB | ES |
-+-------------------+--------------------+----------+----------+----+
-
-+-------------------------+-------------------+----------+--------+----------+--------+----+
-| CONTEXT STATE REPLY CMD | VIRTUAL HOST NAME | CONTEXTA | STATUS | CONTEXTB | STATUS | ES |
-+-------------------------+-------------------+----------+-------------------+--------+----+
-</pre></div>
-
-<ul>
-<li>
-CONTEXT STATE CMD, CONTEXT STATE REPLY CMD, STATUS are 1 byte long.
-</li>
-<li>
-VIRTUAL HOST NAME, CONTEXTs are CString
-</li>
-<li>
-ES is an empty CString
-</li>
-</ul>
-
-NB:<br>
-When VirtualMode is not in use, the VIRTUAL HOST NAME is an empty string.
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Handling of unknown packets"><strong>Handling of unknown packets</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-Sometimes even with a well negocied protocol, we may be in a situation
-where one end (web server or servlet engine), will receive a message it
-couldn't understand. In that case the receiver will send an
-'UNKNOW PACKET CMD' with attached the unhandled message.
-
-<div class="example"><pre>
-+--------------------+------------------------+-------------------+
-| UNKNOWN PACKET CMD | UNHANDLED MESSAGE SIZE | UNHANDLED MESSAGE |
-+--------------------+------------------------+-------------------+
-</pre></div>
-
-Depending on the message, the sender will report an error and if
-possible will try to forward the message to another endpoint.
-
-<ul>
-<li>
-UNKNOWN PACKET CMD is 1 byte long.
-</li>
-<li>
-UNHANDLED MESSAGE SIZE is 16bits long.
-</li>
-<li>
-UNHANDLED MESSAGE is an array of byte (length is contained in UNHANDLED MESSAGE SIZE)
-</li>
-</ul>
-
-NB:<br>
-added UNHANDLED MESSAGE SIZE (development)
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Verification of connection before sending request"><strong>Verification of connection before sending request</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-NOTA: This fonctionality may never be used, since it may slow up the normal process
-since requiring on the web-server side an extra IO (read) before forwarding
-the request.....
-
-One of the beauty of socket APIs, is that you could write on a half closed socket.
-When servlet engine close the socket, the web server will discover it only at the
-next read() to the socket.
-Basically, in the AJP13 protocol, the web server send the HTTP HEADER and HTTP BODY
-(POST by chunk of 8K) to the servlet engine and then try to receive the reply.
-If the connection was broken the web server will learn it only at receive time.
-
-We could use a buffering scheme but what happen when you use the servlet engine
-for upload operations with more than 8ko of datas ?
-
-The hack in the AJP13 protocol is to add some bytes to read after the end of the
-service :
-
-<div class="example"><pre>
-EXAMPLE OF DISCUSSION BETWEEN WEB SERVER AND SERVLET ENGINE
-
-AJP HTTP-HEADER (+ HTTP-POST) (WEB-&gt;SERVLET)
-
-AJP HTTP-REPLY (SERVLET-&gt;WEB)
-
-AJP END OF DISCUSSION (SERVLET-&gt;WEB)
-
----&gt; AJP STATUS (SERVLET-&gt;WEB AJP13)
-</pre></div>
-
-The AJP STATUS will not be read by the servlet engine at the end of
-the request/response #N but at the begining of the next session.
-
-More at that time the web server could also use OS dependants functions
-(or better APR functions) to determine if there is also more data
-to read. And that datas could be CONTEXT Updates.
-
-This will avoid the web server sending a request to a
-desactivated context. In that case, if the load-balancing is used,
-it will search for another servlet engine to handle the request.
-
-And that feature will help ISP and big sites with farm of tomcat,
-to updates their servlet engine without any service interruption.
-
-<div class="example"><pre>
-+------------+-------------+
-| STATUS CMD | STATUS DATA |
-+------------+-------------+
-</pre></div>
-
-<ul>
-<li>
-STATUS CMD and STATUS DATA are one byte long.
-</li>
-</ul>
-</p>
-</blockquote></td></tr></table>
-
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Conclusion"><strong>Conclusion</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-The goal of the extended AJP13 protocol is to overcome some of the original AJP13 limitation.
-An easier configuration, a better support for large site and farm of Tomcat,
-a simple authentification system and provision for protocol updates.
-
-Using the stable ajp13 implementation in JK (native) and in servlet
-engine (java), it's a reasonable evolution of the well known ajp13.
-</p>
-</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#525D76"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Commands and IDs in extended AJP13 Index"><strong>Commands and IDs in extended AJP13 Index</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-Index of Commands and ID to be added in AJP13 Protocol
-</p>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Commands IDs"><strong>Commands IDs</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-<table>
- <tr><th>Command Name</th><th>Command Number</th></tr>
- <tr><td>AJP13_LOGINIT_CMD</td><td>0x10</td></tr>
- <tr><td>AJP13_LOGSEED_CMD</td><td>0x11</td></tr>
- <tr><td>AJP13_LOGCOMP_CMD</td><td>0x12</td></tr>
- <tr><td>AJP13_LOGOK_CMD</td><td>0x13</td></tr>
- <tr><td>AJP13_LOGNOK_CMD</td><td>0x14</td></tr>
- <tr><td>AJP13_CONTEXT_QRY_CMD</td><td>0x15</td></tr>
- <tr><td>AJP13_CONTEXT_INFO_CMD</td><td>0x16</td></tr>
- <tr><td>AJP13_CONTEXT_UPDATE_CMD</td><td>0x17</td></tr>
- <tr><td>AJP13_STATUS_CMD</td><td>0x18</td></tr>
- <tr><td>AJP13_SHUTDOWN_CMD</td><td>0x19</td></tr>
- <tr><td>AJP13_SHUTOK_CMD</td><td>0x1A</td></tr>
- <tr><td>AJP13_SHUTNOK_CMD</td><td>0x1B</td></tr>
- <tr><td>AJP13_CONTEXT_STATE_CMD</td><td>0x1C</td></tr>
- <tr><td>AJP13_CONTEXT_STATE_REP_CMD</td><td>0x1D</td></tr>
- <tr><td>AJP13_UNKNOW_PACKET_CMD</td><td>0x1E</td></tr>
-</table>
-
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Negociations Flags"><strong>Negociations Flags</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-<table>
- <tr><th>Command Name</th><th>Number</th><th>Description</th></tr>
- <tr><td>AJP13_CONTEXT_INFO_NEG</td><td>0x80000000</td><td>web-server want context info after login</td></tr>
- <tr><td>AJP13_CONTEXT_UPDATE_NEG</td><td>0x40000000</td><td>web-server want context updates</td></tr>
- <tr><td>AJP13_GZIP_STREAM_NEG</td><td>0x20000000</td><td>web-server want compressed stream</td></tr>
- <tr><td>AJP13_DES56_STREAM_NEG</td><td>0x10000000</td><td>web-server want crypted DES56 stream with secret key</td></tr>
- <tr><td>AJP13_SSL_VSERVER_NEG</td><td>0x08000000</td><td>Extended info on server SSL vars</td></tr>
- <tr><td>AJP13_SSL_VCLIENT_NEG</td><td>0x04000000</td><td>Extended info on client SSL vars</td></tr>
- <tr><td>AJP13_SSL_VCRYPTO_NEG</td><td>0x02000000</td><td>Extended info on crypto SSL vars</td></tr>
- <tr><td>AJP13_SSL_VMISC_NEG</td><td>0x01000000</td><td>Extended info on misc SSL vars</td></tr>
-</table>
-
-<br>
-
-<table>
- <tr><th>Negociation ID</th><th>Number</th><th>Description</th></tr>
- <tr><td>AJP13_PROTO_SUPPORT_AJPXX_NEG</td><td>0x00FF0000</td><td>mask of protocol supported</td></tr>
- <tr><td>AJP13_PROTO_SUPPORT_AJP13L1_NEG</td><td>0x00010000</td><td>communication could use AJP13 Level 1</td></tr>
- <tr><td>AJP13_PROTO_SUPPORT_AJP13L2_NEG</td><td>0x00020000</td><td>communication could use AJP13 Level 2</td></tr>
- <tr><td>AJP13_PROTO_SUPPORT_AJP13L3_NEG</td><td>0x00040000</td><td>communication could use AJP13 Level 3</td></tr>
-</table>
-
-<br>
-All others flags must be set to 0 since they are reserved for future use.
-
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Failure IDs"><strong>Failure IDs</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-<table>
- <tr><th>Failure Id</th><th>Number</th></tr>
- <tr><td>AJP13_BAD_KEY_ERR</td><td>0xFFFFFFFF</td></tr>
- <tr><td>AJP13_ENGINE_DOWN_ERR</td><td>0xFFFFFFFE</td></tr>
- <tr><td>AJP13_RETRY_LATER_ERR</td><td>0xFFFFFFFD</td></tr>
- <tr><td>AJP13_SHUT_AUTHOR_FAILED_ERR</td><td>0xFFFFFFFC</td></tr>
-</table>
-</p>
-</blockquote></td></tr></table>
-
-<table border="0" cellspacing="0" cellpadding="2" width="100%"><tr><td bgcolor="#828DA6"><font color="#ffffff" face="arial,helvetica.sanserif"><a name="Status"><strong>Status</strong></a></font></td></tr><tr><td><blockquote>
-<p>
-<table>
- <tr><th>Failure Id</th><th>Number</th></tr>
- <tr><td>AJP13_CONTEXT_DOWN</td><td>0x01</td></tr>
- <tr><td>AJP13_CONTEXT_UP</td><td>0x02</td></tr>
- <tr><td>AJP13_CONTEXT_OK</td><td>0x03</td></tr>
-</table>
-</p>
-</blockquote></td></tr></table>
-
-</blockquote></td></tr></table></td></tr><!--FOOTER SEPARATOR--><tr><td colspan="2"><hr noshade size="1"></td></tr><!--PAGE FOOTER--><tr><td colspan="2"><div align="center"><font color="#525D76" size="-1"><em>
- Copyright &copy; 1999-2011, Apache Software Foundation
- </em></font></div></td></tr></table></body></html> \ No newline at end of file