--- /dev/null
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><!--
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ This file is generated from xml source: DO NOT EDIT
+ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
+ -->
+<title>mod_proxy_ajp - Apache HTTP Server</title>
+<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
+<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
+<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" />
+<link href="../images/favicon.ico" rel="shortcut icon" /></head>
+<body>
+<div id="page-header">
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p>
+<p class="apache">Apache HTTP Server Version 2.1</p>
+<img alt="" src="../images/feather.gif" /></div>
+<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
+<div id="path">
+<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">HTTP Server</a> > <a href="http://httpd.apache.org/docs-project/">Documentation</a> > <a href="../">Version 2.1</a> > <a href="./">Modules</a></div>
+<div id="page-content">
+<div id="preamble"><h1>Apache Module mod_proxy_ajp</h1>
+<div class="toplang">
+<p><span>Available Languages: </span><a href="../en/mod/mod_proxy_ajp.html" title="English"> en </a></p>
+</div>
+<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>AJP support module for
+<code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></td></tr>
+<tr><th><a href="module-dict.html#Status">Status:</a></th><td>Extension</td></tr>
+<tr><th><a href="module-dict.html#ModuleIdentifier">Module Identifier:</a></th><td>proxy_ajp_module</td></tr>
+<tr><th><a href="module-dict.html#SourceFile">Source File:</a></th><td>proxy_ajp.c</td></tr></table>
+<h3>Summary</h3>
+
+ <p>This module <em>requires</em> the service of <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code>. It provides support for the
+ <code>Apache JServ Protocol version 1.3</code> (hereafter
+ <em>AJP13</em>).</p>
+
+ <p>Thus, in order to get the ability of handling <code>AJP13</code>
+ protocol, <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> and
+ <code class="module"><a href="../mod/mod_proxy_ajp.html">mod_proxy_ajp</a></code> have to be present in the server.</p>
+
+ <div class="warning"><h3>Warning</h3>
+ <p>Do not enable proxying until you have <a href="mod_proxy.html#access">secured your server</a>. Open proxy
+ servers are dangerous both to your network and to the Internet at
+ large.</p>
+ </div>
+</div>
+<div id="quickview"><h3 class="directives">Directives</h3>
+<p>This module provides no
+ directives.</p>
+<h3>Topics</h3>
+<ul id="topics">
+<li><img alt="" src="../images/down.gif" /> <a href="#overviewprotocol">Overview of the protocol</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#basppacketstruct">Basic Packet Structure</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#rpacetstruct">Request Packet Structure</a></li>
+<li><img alt="" src="../images/down.gif" /> <a href="#resppacketstruct">Response Packet Structure</a></li>
+</ul><h3>See also</h3>
+<ul class="seealso">
+<li><code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code></li>
+</ul></div>
+<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="overviewprotocol" id="overviewprotocol">Overview of the protocol</a></h2>
+ <p>The <code>AJP13</code> 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 <code>(content-length > 0)</code>, 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>
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="basppacketstruct" id="basppacketstruct">Basic Packet Structure</a></h2>
+ <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><strong>Byte</strong></dt><dd>A single byte.</dd>
+ <dt><strong>Boolean</strong></dt>
+ <dd>A single byte, <code>1 = true</code>, <code>0 = false</code>.
+ Using other non-zero values as true (i.e. C-style) may work in some places,
+ but it won't in others.</dd>
+ <dt><strong>Integer</strong></dt>
+ <dd>A number in the range of <code>0 to 2^16 (32768)</code>. Stored in
+ 2 bytes with the high-order byte first.</dd>
+ <dt><strong>String</strong></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
+ <strong>not</strong> include the trailing '\0' -- it is like
+ <code>strlen</code>. 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.</dd>
+ </dl></p>
+
+ <h3>Packet Size</h3>
+ <p>According to much of the code, the max packet size is <code>
+ 8 * 1024 bytes (8K)</code>. The actual length of the packet is encoded in
+ the header.</p>
+
+ <h3>Packet Headers</h3>
+ <p>Packets sent from the server to the container begin with
+ <code>0x1234</code>. Packets sent from the container to the server
+ begin with <code>AB</code> (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>
+ <td colspan="6"><em>Packet Format (Server->Container)</em></td>
+ </tr>
+ <tr>
+ <td>Byte</td>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <td>Contents</td>
+ <td>0x12</td>
+ <td>0x34</td>
+ <td colspan="2">Data Length (n)</td>
+ <td>Data</td>
+ </tr>
+ </table>
+ <table>
+ <tr>
+ <td colspan="6"><em>Packet Format (Container->Server)</em></td>
+ </tr>
+ <tr>
+ <td>Byte</td>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <td>Contents</td>
+ <td>A</td>
+ <td>B</td>
+ <td colspan="2">Data Length (n)</td>
+ <td>Data</td>
+ </tr>
+ </table></p>
+ <p>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 (<code>
+ 0x1234</code> and then length of the packet), but without any prefix code
+ after that.</p>
+ <p>The web server can send the following messages to the servlet container:
+ <table>
+ <tr>
+ <td>Code</td>
+ <td>Type of Packet</td>
+ <td>Meaning</td>
+ </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
+ <code>Shutdown</code> if the request comes from the same machine on which
+ it's hosted.</p>
+ <p>The first <code>Data</code> packet is send immediatly after the
+ <code>Forward Request</code> by the web server.</p>
+ <p>The servlet container can send the following types of messages to the
+ webserver:
+ <table>
+ <tr>
+ <td>Code</td>
+ <td>Type of Packet</td>
+ <td>Meaning</td>
+ </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>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="rpacetstruct" id="rpacetstruct">Request Packet Structure</a></h2>
+ <p>For messages from the server to the container of type
+ <em>Forward Request</em>:</p>
+ <div class="example"><pre>
+AJP13_FORWARD_REQUEST :=
+ prefix_code (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
+ method (byte)
+ protocol (string)
+ req_uri (string)
+ remote_addr (string)
+ remote_host (string)
+ server_name (string)
+ server_port (integer)
+ is_ssl (boolean)
+ num_headers (integer)
+ request_headers *(req_header_name req_header_value)
+ attributes *(attribut_name attribute_value)
+ request_terminator (byte) OxFF
+ </pre></div>
+ <p>The <code>request_headers</code> have the following structure:
+ </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>The <code>attributes</code> are optional and have the following
+ structure:</p>
+ <div class="example"><pre>
+attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+
+ </pre></div>
+ <p>Not that the all-important header is <code>content-length</code>,
+ because it determines whether or not the container looks for another
+ packet immediately.</p>
+ <h3>Detailed description of the elements of Forward Request
+ </h3>
+ <h3>Request prefix</h3>
+ <p>For all requests, this will be 2. See above for details on other Prefix
+ codes.</p>
+
+ <h3>Method</h3>
+ <p>The HTTP method, encoded as a single byte:</p>
+ <p><table>
+ <tr><td>Command Name</td><td>Code</td></tr>
+ <tr><td>OPTIONS</td><td>1</td></tr>
+ <tr><td>GET</td><td>2</td></tr>
+ <tr><td>HEAD</td><td>3</td></tr>
+ <tr><td>POST</td><td>4</td></tr>
+ <tr><td>PUT</td><td>5</td></tr>
+ <tr><td>DELETE</td><td>6</td></tr>
+ <tr><td>TRACE</td><td>7</td></tr>
+ <tr><td>PROPFIND</td><td>8</td></tr>
+ <tr><td>PROPPATCH</td><td>9</td></tr>
+ <tr><td>MKCOL</td><td>10</td></tr>
+ <tr><td>COPY</td><td>11</td></tr>
+ <tr><td>MOVE</td><td>12</td></tr>
+ <tr><td>LOCK</td><td>13</td></tr>
+ <tr><td>UNLOCK</td><td>14</td></tr>
+ <tr><td>ACL</td><td>15</td></tr>
+ <tr><td>REPORT</td><td>16</td></tr>
+ <tr><td>VERSION-CONTROL</td><td>17</td></tr>
+ <tr><td>CHECKIN</td><td>18</td></tr>
+ <tr><td>CHECKOUT</td><td>19</td></tr>
+ <tr><td>UNCHECKOUT</td><td>20</td></tr>
+ <tr><td>SEARCH</td><td>21</td></tr>
+ <tr><td>MKWORKSPACE</td><td>22</td></tr>
+ <tr><td>UPDATE</td><td>23</td></tr>
+ <tr><td>LABEL</td><td>24</td></tr>
+ <tr><td>MERGE</td><td>25</td></tr>
+ <tr><td>BASELINE_CONTROL</td><td>26</td></tr>
+ <tr><td>MKACTIVITY</td><td>27</td></tr>
+ </table></p>
+ <p>Later version of ajp13, will transport
+ additional methods, even if they are not in this list.</p>
+
+ <h3>protocol, req_uri, remote_addr, remote_host, server_name,
+ server_port, is_ssl</h3>
+ <p>These are all fairly self-explanatory. Each of these is required, and
+ will be sent for every request.</p>
+
+ <h3>Headers</h3>
+ <p>The structure of <code>request_headers</code> is the following:
+ First, the number of headers <code>num_headers</code> is encoded.
+ Then, a series of header name <code>req_header_name</code> / value
+ <code>req_header_value</code> 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 <code>sc_req_header_name</code>and their codes
+ is as follows (all are case-sensitive):</p>
+ <p><table>
+ <tr><td>Name</td><td>Code value</td><td>Code name</td></tr>
+ <tr><td>accept</td><td>0xA001</td><td>SC_REQ_ACCEPT</td></tr>
+ <tr><td>accept-charset</td><td>0xA002</td><td>SC_REQ_ACCEPT_CHARSET
+ </td></tr>
+ <tr><td>accept-encoding</td><td>0xA003</td><td>SC_REQ_ACCEPT_ENCODING
+ </td></tr>
+ <tr><td>accept-language</td><td>0xA004</td><td>SC_REQ_ACCEPT_LANGUAGE
+ </td></tr>
+ <tr><td>authorization</td><td>0xA005</td><td>SC_REQ_AUTHORIZATION</td>
+ </tr>
+ <tr><td>connection</td><td>0xA006</td><td>SC_REQ_CONNECTION</td></tr>
+ <tr><td>content-type</td><td>0xA007</td><td>SC_REQ_CONTENT_TYPE</td>
+ </tr>
+ <tr><td>content-length</td><td>0xA008</td><td>SC_REQ_CONTENT_LENGTH</td>
+ </tr>
+ <tr><td>cookie</td><td>0xA009</td><td>SC_REQ_COOKIE</td></tr>
+ <tr><td>cookie2</td><td>0xA00A</td><td>SC_REQ_COOKIE2</td></tr>
+ <tr><td>host</td><td>0xA00B</td><td>SC_REQ_HOST</td></tr>
+ <tr><td>pragma</td><td>0xA00C</td><td>SC_REQ_PRAGMA</td></tr>
+ <tr><td>referer</td><td>0xA00D</td><td>SC_REQ_REFERER</td></tr>
+ <tr><td>user-agent</td><td>0xA00E</td><td>SC_REQ_USER_AGENT</td></tr>
+ </table></p>
+ <p>The Java code that reads this grabs the first two-byte integer and if
+ it sees an <code>'0xA0'</code> 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 <code>0xA0</code>, 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 <code>0x9999 (==0xA000 - 1)</code>, which is perfectly
+ reasonable, though somewhat arbitrary.</p>
+ <div class="note"><h3>Note:</h3>
+ The <code>content-length</code> 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.
+ </div>
+
+ <h3>Attributes</h3>
+ <p>The attributes prefixed with a <code>?</code>
+ (e.g. <code>?context</code>) 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><td>Information</td><td>Code Value</td><td>Note</td></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 /></tr>
+ <tr><td>?auth_type</td><td>0x04</td><td /></tr>
+ <tr><td>?query_string</td><td>0x05</td><td /></tr>
+ <tr><td>?jvm_route</td><td>0x06</td><td /></tr>
+ <tr><td>?ssl_cert</td><td>0x07</td><td /></tr>
+ <tr><td>?ssl_cipher</td><td>0x08</td><td /></tr>
+ <tr><td>?ssl_session</td><td>0x09</td><td /></tr>
+ <tr><td>?req_attribute</td><td>0x0A</td><td>Name (the name of the
+ attribute follows)</td></tr>
+ <tr><td>?ssl_key_size</td><td>0x0B</td><td /></tr>
+ <tr><td>are_done</td><td>0xFF</td><td>request_terminator</td></tr>
+ </table></p>
+ <p>The <code>context</code> and <code>servlet_path</code> 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 <code>remote_user</code> and <code>auth_type</code> 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).</p>
+ <p>The <code>query_string</code>, <code>ssl_cert</code>,
+ <code>ssl_cipher</code>, and <code>ssl_session</code> refer to the
+ corresponding pieces of HTTP and HTTPS.</p>
+ <p>The <code>jvm_route</code>, is used to support sticky
+ sessions -- associating a user's sesson with a particular Tomcat instance
+ in the presence of multiple, load-balancing servers.</p>
+ <p>Beyond this list of basic attributes, any number of other attributes
+ can be sent via the <code>req_attribute</code> code <code>0x0A</code>.
+ 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, <code>0xFF</code>, is sent. This signals both the end of the
+ list of attributes and also then end of the Request Packet.</p>
+
+</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
+<div class="section">
+<h2><a name="resppacketstruct" id="resppacketstruct">Response Packet Structure</a></h2>
+ <p>for messages which the container can send back to the server.</p>
+ <div class="example"><pre>
+AJP13_SEND_BODY_CHUNK :=
+ prefix_code 3
+ chunk_length (integer)
+ chunk *(byte)
+
+
+AJP13_SEND_HEADERS :=
+ prefix_code 4
+ http_status_code (integer)
+ http_status_msg (string)
+ num_headers (integer)
+ response_headers *(res_header_name header_value)
+
+res_header_name :=
+ sc_res_header_name | (string) [see below for how this is parsed]
+
+sc_res_header_name := 0xA0 (byte)
+
+header_value := (string)
+
+AJP13_END_RESPONSE :=
+ prefix_code 5
+ reuse (boolean)
+
+
+AJP13_GET_BODY_CHUNK :=
+ prefix_code 6
+ requested_length (integer)
+ </pre></div>
+ <h3>Details:</h3>
+ <h3>Send Body Chunk</h3>
+ <p>The chunk is basically binary data, and is sent directly back to the
+ browser.</p>
+
+ <h3>Send Headers</h3>
+ <p>The status code and message are the usual HTTP things
+ (e.g. <code>200</code> and <code>OK</code>). The response header names are
+ encoded the same way the request header names are. See header_encoding above
+ for details about how the the codes are distinguished from the strings.<br />
+ The codes for common headers are:</p>
+ <p><table>
+ <tr><td>Name</td><td>Code value</td></tr>
+ <tr><td>Content-Type</td><td>0xA001</td></tr>
+ <tr><td>Content-Language</td><td>0xA002</td></tr>
+ <tr><td>Content-Length</td><td>0xA003</td></tr>
+ <tr><td>Date</td><td>0xA004</td></tr>
+ <tr><td>Last-Modified</td><td>0xA005</td></tr>
+ <tr><td>Location</td><td>0xA006</td></tr>
+ <tr><td>Set-Cookie</td><td>0xA007</td></tr>
+ <tr><td>Set-Cookie2</td><td>0xA008</td></tr>
+ <tr><td>Servlet-Engine</td><td>0xA009</td></tr>
+ <tr><td>Status</td><td>0xA00A</td></tr>
+ <tr><td>WWW-Authenticate</td><td>0xA00B</td></tr>
+ </table></p>
+ <p> After the code or the string header name, the header value is
+ immediately encoded.</p>
+
+ <h3>End Response</h3>
+ <p>Signals the end of this request-handling cycle. If the
+ <code>reuse</code> flag is true <code>(==1)</code>, this TCP connection can
+ now be used to handle new incoming requests. If <code>reuse</code> is false
+ (anything other than 1 in the actual C code), the connection should
+ be closed.</p>
+
+ <h3>Get Body Chunk</h3>
+ <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 <code>request_length</code>, the maximum send
+ body size <code>(8186 (8 Kbytes - 6))</code>, 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
+ <em>empty</em> packet, which is a body packet with a payload length of 0.
+ <code>(0x12,0x34,0x00,0x00)</code></p>
+
+</div>
+</div>
+<div class="bottomlang">
+<p><span>Available Languages: </span><a href="../en/mod/mod_proxy_ajp.html" title="English"> en </a></p>
+</div><div id="footer">
+<p class="apache">Copyright 1999-2004 The Apache Software Foundation.<br />Licensed under the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
+<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/directives.html">Directives</a> | <a href="../faq/">FAQ</a> | <a href="../glossary.html">Glossary</a> | <a href="../sitemap.html">Sitemap</a></p></div>
+</body></html>
\ No newline at end of file
--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
+<?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
+<!-- $Revision: 1.1 $ -->
+
+<!--
+ Copyright 2002-2004 The Apache Software Foundation
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+
+<modulesynopsis metafile="mod_proxy_ajp.xml.meta">
+
+<name>mod_proxy_ajp</name>
+<description>AJP support module for
+<module>mod_proxy</module></description>
+<status>Extension</status>
+<sourcefile>proxy_ajp.c</sourcefile>
+<identifier>proxy_ajp_module</identifier>
+
+<summary>
+ <p>This module <em>requires</em> the service of <module
+ >mod_proxy</module>. It provides support for the
+ <code>Apache JServ Protocol version 1.3</code> (hereafter
+ <em>AJP13</em>).</p>
+
+ <p>Thus, in order to get the ability of handling <code>AJP13</code>
+ protocol, <module>mod_proxy</module> and
+ <module>mod_proxy_ajp</module> have to be present in the server.</p>
+
+ <note type="warning"><title>Warning</title>
+ <p>Do not enable proxying until you have <a
+ href="mod_proxy.html#access">secured your server</a>. Open proxy
+ servers are dangerous both to your network and to the Internet at
+ large.</p>
+ </note>
+</summary>
+
+<section id="overviewprotocol"><title>Overview of the protocol</title>
+ <p>The <code>AJP13</code> 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 <code>(content-length > 0)</code>, 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>
+</section>
+
+<section id="basppacketstruct"><title>Basic Packet Structure</title>
+ <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><strong>Byte</strong></dt><dd>A single byte.</dd>
+ <dt><strong>Boolean</strong></dt>
+ <dd>A single byte, <code>1 = true</code>, <code>0 = false</code>.
+ Using other non-zero values as true (i.e. C-style) may work in some places,
+ but it won't in others.</dd>
+ <dt><strong>Integer</strong></dt>
+ <dd>A number in the range of <code>0 to 2^16 (32768)</code>. Stored in
+ 2 bytes with the high-order byte first.</dd>
+ <dt><strong>String</strong></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
+ <strong>not</strong> include the trailing '\0' -- it is like
+ <code>strlen</code>. 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.</dd>
+ </dl></p>
+
+ <section><title>Packet Size</title>
+ <p>According to much of the code, the max packet size is <code>
+ 8 * 1024 bytes (8K)</code>. The actual length of the packet is encoded in
+ the header.</p>
+ </section>
+ <section><title>Packet Headers</title>
+ <p>Packets sent from the server to the container begin with
+ <code>0x1234</code>. Packets sent from the container to the server
+ begin with <code>AB</code> (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>
+ <td colspan="6"><em>Packet Format (Server->Container)</em></td>
+ </tr>
+ <tr>
+ <td>Byte</td>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <td>Contents</td>
+ <td>0x12</td>
+ <td>0x34</td>
+ <td colspan="2">Data Length (n)</td>
+ <td>Data</td>
+ </tr>
+ </table>
+ <table>
+ <tr>
+ <td colspan="6"><em>Packet Format (Container->Server)</em></td>
+ </tr>
+ <tr>
+ <td>Byte</td>
+ <td>0</td>
+ <td>1</td>
+ <td>2</td>
+ <td>3</td>
+ <td>4...(n+3)</td>
+ </tr>
+ <tr>
+ <td>Contents</td>
+ <td>A</td>
+ <td>B</td>
+ <td colspan="2">Data Length (n)</td>
+ <td>Data</td>
+ </tr>
+ </table></p>
+ <p>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 (<code>
+ 0x1234</code> and then length of the packet), but without any prefix code
+ after that.</p>
+ <p>The web server can send the following messages to the servlet container:
+ <table>
+ <tr>
+ <td>Code</td>
+ <td>Type of Packet</td>
+ <td>Meaning</td>
+ </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
+ <code>Shutdown</code> if the request comes from the same machine on which
+ it's hosted.</p>
+ <p>The first <code>Data</code> packet is send immediatly after the
+ <code>Forward Request</code> by the web server.</p>
+ <p>The servlet container can send the following types of messages to the
+ webserver:
+ <table>
+ <tr>
+ <td>Code</td>
+ <td>Type of Packet</td>
+ <td>Meaning</td>
+ </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>
+ </section>
+</section>
+<section id="rpacetstruct"><title>Request Packet Structure</title>
+ <p>For messages from the server to the container of type
+ <em>Forward Request</em>:</p>
+ <example><pre>
+AJP13_FORWARD_REQUEST :=
+ prefix_code (byte) 0x02 = JK_AJP13_FORWARD_REQUEST
+ method (byte)
+ protocol (string)
+ req_uri (string)
+ remote_addr (string)
+ remote_host (string)
+ server_name (string)
+ server_port (integer)
+ is_ssl (boolean)
+ num_headers (integer)
+ request_headers *(req_header_name req_header_value)
+ attributes *(attribut_name attribute_value)
+ request_terminator (byte) OxFF
+ </pre></example>
+ <p>The <code>request_headers</code> have the following structure:
+ </p><example><pre>
+req_header_name :=
+ sc_req_header_name | (string) [see below for how this is parsed]
+
+sc_req_header_name := 0xA0xx (integer)
+
+req_header_value := (string)
+</pre></example>
+ <p>The <code>attributes</code> are optional and have the following
+ structure:</p>
+ <example><pre>
+attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+
+ </pre></example>
+ <p>Not that the all-important header is <code>content-length</code>,
+ because it determines whether or not the container looks for another
+ packet immediately.</p>
+ <section><title>Detailed description of the elements of Forward Request
+ </title></section>
+ <section><title>Request prefix</title>
+ <p>For all requests, this will be 2. See above for details on other Prefix
+ codes.</p>
+ </section>
+ <section><title>Method</title>
+ <p>The HTTP method, encoded as a single byte:</p>
+ <p><table>
+ <tr><td>Command Name</td><td>Code</td></tr>
+ <tr><td>OPTIONS</td><td>1</td></tr>
+ <tr><td>GET</td><td>2</td></tr>
+ <tr><td>HEAD</td><td>3</td></tr>
+ <tr><td>POST</td><td>4</td></tr>
+ <tr><td>PUT</td><td>5</td></tr>
+ <tr><td>DELETE</td><td>6</td></tr>
+ <tr><td>TRACE</td><td>7</td></tr>
+ <tr><td>PROPFIND</td><td>8</td></tr>
+ <tr><td>PROPPATCH</td><td>9</td></tr>
+ <tr><td>MKCOL</td><td>10</td></tr>
+ <tr><td>COPY</td><td>11</td></tr>
+ <tr><td>MOVE</td><td>12</td></tr>
+ <tr><td>LOCK</td><td>13</td></tr>
+ <tr><td>UNLOCK</td><td>14</td></tr>
+ <tr><td>ACL</td><td>15</td></tr>
+ <tr><td>REPORT</td><td>16</td></tr>
+ <tr><td>VERSION-CONTROL</td><td>17</td></tr>
+ <tr><td>CHECKIN</td><td>18</td></tr>
+ <tr><td>CHECKOUT</td><td>19</td></tr>
+ <tr><td>UNCHECKOUT</td><td>20</td></tr>
+ <tr><td>SEARCH</td><td>21</td></tr>
+ <tr><td>MKWORKSPACE</td><td>22</td></tr>
+ <tr><td>UPDATE</td><td>23</td></tr>
+ <tr><td>LABEL</td><td>24</td></tr>
+ <tr><td>MERGE</td><td>25</td></tr>
+ <tr><td>BASELINE_CONTROL</td><td>26</td></tr>
+ <tr><td>MKACTIVITY</td><td>27</td></tr>
+ </table></p>
+ <p>Later version of ajp13, will transport
+ additional methods, even if they are not in this list.</p>
+ </section>
+ <section><title>protocol, req_uri, remote_addr, remote_host, server_name,
+ server_port, is_ssl</title>
+ <p>These are all fairly self-explanatory. Each of these is required, and
+ will be sent for every request.</p>
+ </section>
+ <section><title>Headers</title>
+ <p>The structure of <code>request_headers</code> is the following:
+ First, the number of headers <code>num_headers</code> is encoded.
+ Then, a series of header name <code>req_header_name</code> / value
+ <code>req_header_value</code> 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 <code>sc_req_header_name</code>and their codes
+ is as follows (all are case-sensitive):</p>
+ <p><table>
+ <tr><td>Name</td><td>Code value</td><td>Code name</td></tr>
+ <tr><td>accept</td><td>0xA001</td><td>SC_REQ_ACCEPT</td></tr>
+ <tr><td>accept-charset</td><td>0xA002</td><td>SC_REQ_ACCEPT_CHARSET
+ </td></tr>
+ <tr><td>accept-encoding</td><td>0xA003</td><td>SC_REQ_ACCEPT_ENCODING
+ </td></tr>
+ <tr><td>accept-language</td><td>0xA004</td><td>SC_REQ_ACCEPT_LANGUAGE
+ </td></tr>
+ <tr><td>authorization</td><td>0xA005</td><td>SC_REQ_AUTHORIZATION</td>
+ </tr>
+ <tr><td>connection</td><td>0xA006</td><td>SC_REQ_CONNECTION</td></tr>
+ <tr><td>content-type</td><td>0xA007</td><td>SC_REQ_CONTENT_TYPE</td>
+ </tr>
+ <tr><td>content-length</td><td>0xA008</td><td>SC_REQ_CONTENT_LENGTH</td>
+ </tr>
+ <tr><td>cookie</td><td>0xA009</td><td>SC_REQ_COOKIE</td></tr>
+ <tr><td>cookie2</td><td>0xA00A</td><td>SC_REQ_COOKIE2</td></tr>
+ <tr><td>host</td><td>0xA00B</td><td>SC_REQ_HOST</td></tr>
+ <tr><td>pragma</td><td>0xA00C</td><td>SC_REQ_PRAGMA</td></tr>
+ <tr><td>referer</td><td>0xA00D</td><td>SC_REQ_REFERER</td></tr>
+ <tr><td>user-agent</td><td>0xA00E</td><td>SC_REQ_USER_AGENT</td></tr>
+ </table></p>
+ <p>The Java code that reads this grabs the first two-byte integer and if
+ it sees an <code>'0xA0'</code> 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 <code>0xA0</code>, 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 <code>0x9999 (==0xA000 - 1)</code>, which is perfectly
+ reasonable, though somewhat arbitrary.</p>
+ <note><title>Note:</title>
+ The <code>content-length</code> 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.
+ </note>
+ </section>
+ <section><title>Attributes</title>
+ <p>The attributes prefixed with a <code>?</code>
+ (e.g. <code>?context</code>) 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><td>Information</td><td>Code Value</td><td>Note</td></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>?jvm_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
+ attribute follows)</td></tr>
+ <tr><td>?ssl_key_size</td><td>0x0B</td><td></td></tr>
+ <tr><td>are_done</td><td>0xFF</td><td>request_terminator</td></tr>
+ </table></p>
+ <p>The <code>context</code> and <code>servlet_path</code> 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 <code>remote_user</code> and <code>auth_type</code> 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).</p>
+ <p>The <code>query_string</code>, <code>ssl_cert</code>,
+ <code>ssl_cipher</code>, and <code>ssl_session</code> refer to the
+ corresponding pieces of HTTP and HTTPS.</p>
+ <p>The <code>jvm_route</code>, is used to support sticky
+ sessions -- associating a user's sesson with a particular Tomcat instance
+ in the presence of multiple, load-balancing servers.</p>
+ <p>Beyond this list of basic attributes, any number of other attributes
+ can be sent via the <code>req_attribute</code> code <code>0x0A</code>.
+ 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, <code>0xFF</code>, is sent. This signals both the end of the
+ list of attributes and also then end of the Request Packet.</p>
+ </section>
+</section>
+
+<section id="resppacketstruct"><title>Response Packet Structure</title>
+ <p>for messages which the container can send back to the server.</p>
+ <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></example>
+ <section><title>Details:</title></section>
+ <section><title>Send Body Chunk</title>
+ <p>The chunk is basically binary data, and is sent directly back to the
+ browser.</p>
+ </section>
+ <section><title>Send Headers</title>
+ <p>The status code and message are the usual HTTP things
+ (e.g. <code>200</code> and <code>OK</code>). The response header names are
+ encoded the same way the request header names are. See header_encoding above
+ for details about how the the codes are distinguished from the strings.<br />
+ The codes for common headers are:</p>
+ <p><table>
+ <tr><td>Name</td><td>Code value</td></tr>
+ <tr><td>Content-Type</td><td>0xA001</td></tr>
+ <tr><td>Content-Language</td><td>0xA002</td></tr>
+ <tr><td>Content-Length</td><td>0xA003</td></tr>
+ <tr><td>Date</td><td>0xA004</td></tr>
+ <tr><td>Last-Modified</td><td>0xA005</td></tr>
+ <tr><td>Location</td><td>0xA006</td></tr>
+ <tr><td>Set-Cookie</td><td>0xA007</td></tr>
+ <tr><td>Set-Cookie2</td><td>0xA008</td></tr>
+ <tr><td>Servlet-Engine</td><td>0xA009</td></tr>
+ <tr><td>Status</td><td>0xA00A</td></tr>
+ <tr><td>WWW-Authenticate</td><td>0xA00B</td></tr>
+ </table></p>
+ <p> After the code or the string header name, the header value is
+ immediately encoded.</p>
+ </section>
+ <section><title>End Response</title>
+ <p>Signals the end of this request-handling cycle. If the
+ <code>reuse</code> flag is true <code>(==1)</code>, this TCP connection can
+ now be used to handle new incoming requests. If <code>reuse</code> is false
+ (anything other than 1 in the actual C code), the connection should
+ be closed.</p>
+ </section>
+ <section><title>Get Body Chunk</title>
+ <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 <code>request_length</code>, the maximum send
+ body size <code>(8186 (8 Kbytes - 6))</code>, 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
+ <em>empty</em> packet, which is a body packet with a payload length of 0.
+ <code>(0x12,0x34,0x00,0x00)</code></p>
+ </section>
+</section>
+
+<seealso><module>mod_proxy</module></seealso>
+
+</modulesynopsis>
projects / apache / commitdiff