| <?xml version="1.0"?> |
| <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> |
| <!-- $LastChangedRevision$ --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You 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>mod_proxy_ajp.c</sourcefile> |
| <identifier>proxy_ajp_module</identifier> |
| <compatibility>Available in version 2.1 and later</compatibility> |
| |
| <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> |
| |
| <seealso><module>mod_proxy</module></seealso> |
| <seealso><a href="../env.html">Environment Variable documentation</a></seealso> |
| |
| <section id="usage"><title>Usage</title> |
| <p>This module is used to reverse proxy to a backend application server |
| (e.g. Apache Tomcat) using the AJP13 protocol. The usage is similar to |
| an HTTP reverse proxy, but uses the <code>ajp://</code> prefix:</p> |
| |
| <example><title>Simple Reverse Proxy</title> |
| <highlight language="config"> |
| ProxyPass "/app" "ajp://backend.example.com:8009/app" |
| </highlight> |
| </example> |
| |
| <p>Balancers may also be used:</p> |
| <example><title>Balancer Reverse Proxy</title> |
| <highlight language="config"> |
| <Proxy "balancer://cluster"> |
| BalancerMember "ajp://app1.example.com:8009" loadfactor=1 |
| BalancerMember "ajp://app2.example.com:8009" loadfactor=2 |
| ProxySet lbmethod=bytraffic |
| </Proxy> |
| ProxyPass "/app" "balancer://cluster/app" |
| </highlight> |
| </example> |
| |
| <p>Note that usually no |
| <directive module="mod_proxy">ProxyPassReverse</directive> |
| directive is necessary. The AJP request includes the original host |
| header given to the proxy, and the application server can be expected |
| to generate self-referential headers relative to this host, so no |
| rewriting is necessary.</p> |
| |
| <p>The main exception is when the URL path on the proxy differs from that |
| on the |
| backend. In this case, a redirect header can be rewritten relative to the |
| original host URL (not the backend <code>ajp://</code> URL), for |
| example:</p> |
| <example><title>Rewriting Proxied Path</title> |
| <highlight language="config"> |
| ProxyPass "/apps/foo" "ajp://backend.example.com:8009/foo" |
| ProxyPassReverse "/apps/foo" "http://www.example.com/foo" |
| </highlight> |
| </example> |
| <p>However, it is usually better to deploy the application on the backend |
| server at the same path as the proxy rather than to take this approach. |
| </p> |
| </section> |
| |
| <section id="env"><title>Environment Variables</title> |
| <p>Environment variables whose names have the prefix <code>AJP_</code> |
| are forwarded to the origin server as AJP request attributes |
| (with the AJP_ prefix removed from the name of the key).</p> |
| </section> |
| |
| <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> |
| <ul> |
| <li> Idle <br/> No request is being handled over this connection. </li> |
| <li> Assigned <br/> The connection is handling a specific request.</li> |
| </ul> |
| <p>Once a connection is assigned to handle a particular request, the basic |
| request information (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:</p> |
| <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 transfer).</li> |
| <li>END_RESPONSE <br/> Finish the request-handling cycle.</li> |
| </ul> |
| <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>AJP13 uses network byte order for all data types.</p> |
| <p>There are four data types in the protocol: bytes, booleans, |
| integers and strings.</p> |
| <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> |
| |
| <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.</p> |
| <table> |
| <columnspec><column width=".2"/><column width=".1"/><column width=".1"/><column width=".2"/><column width=".2"/><column width=".2"/></columnspec> |
| <tr> |
| <th colspan="6"><em>Packet Format (Server->Container)</em></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> |
| <columnspec><column width=".2"/><column width=".1"/><column width=".1"/><column width=".2"/><column width=".2"/><column width=".2"/></columnspec> |
| <tr> |
| <th colspan="6"><em>Packet Format (Container->Server)</em></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>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:</p> |
| <table> |
| <columnspec><column width=".2"/><column width=".3"/><column width=".5"/></columnspec> |
| <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>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 immediately 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:</p> |
| <table> |
| <columnspec><column width=".2"/><column width=".3"/><column width=".5"/></columnspec> |
| <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>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> |
| <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>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> |
| <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>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>0x9FFF (==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 its value |
| (string or integer). They can be sent in any order (though 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> |
| <table> |
| <tr><td>Information</td><td>Code Value</td><td>Type Of Value</td><td>Note</td></tr> |
| <tr><td>?context</td><td>0x01</td><td>-</td><td>Not currently implemented |
| </td></tr> |
| <tr><td>?servlet_path</td><td>0x02</td><td>-</td><td>Not currently implemented |
| </td></tr> |
| <tr><td>?remote_user</td><td>0x03</td><td>String</td><td></td></tr> |
| <tr><td>?auth_type</td><td>0x04</td><td>String</td><td></td></tr> |
| <tr><td>?query_string</td><td>0x05</td><td>String</td><td></td></tr> |
| <tr><td>?jvm_route</td><td>0x06</td><td>String</td><td></td></tr> |
| <tr><td>?ssl_cert</td><td>0x07</td><td>String</td><td></td></tr> |
| <tr><td>?ssl_cipher</td><td>0x08</td><td>String</td><td></td></tr> |
| <tr><td>?ssl_session</td><td>0x09</td><td>String</td><td></td></tr> |
| <tr><td>?req_attribute</td><td>0x0A</td><td>String</td><td>Name (the name of the |
| attribute follows)</td></tr> |
| <tr><td>?ssl_key_size</td><td>0x0B</td><td>Integer</td><td></td></tr> |
| <tr><td>are_done</td><td>0xFF</td><td>-</td><td>request_terminator</td></tr> |
| </table> |
| <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) |
| chunk_terminator (byte) Ox00 |
| |
| |
| 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 codes are distinguished from the strings.<br /> |
| The codes for common headers are:</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> 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>(anything other than 0 in the actual |
| C code)</code>, this TCP connection can now be used to handle new incoming |
| requests. If <code>reuse</code> is false (==0), 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 |
| chunked). 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> |
| |
| |
| </modulesynopsis> |