mturk 2004/11/18 10:24:08
Added: jk/xdocs/common ajpv13a.xml ajpv13ext.xml project.xml
Log:
Add new contrib docs
Revision ChangesPath
1.1 jakarta-tomcat-connectors/jk/xdocs/common/ajpv13a.xml
Index: ajpv13a.xml
===
]>
&project;
Copyright 1999-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.
AJPv13
[EMAIL PROTECTED]
Jean-Frederic Clere
$Date: 2004/11/18 18:24:08 $
The original document was written by
Dan Milstein, [EMAIL PROTECTED]
on December 2000. The present document is generated out of an xml file
to allow a more easy integration in the Tomcat documentation.
This describes the Apache JServ Protocol version 1.3 (hereafter
ajp13). 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).
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.
According to email from Gal Shachor to the jakarta-dev mailing list,
the original goals of JK (and thus ajp13) were to extend
mod_jserv and ajp12 by (I am only including the goals which
relate to communication between the web server and the servlet container):
Increasing performance (speed, specifically).
Adding support for SSL, so that isSecure() and
geScheme() will function correctly within the servlet
container. The client certificates and cipher suite will be
available to servlets as request attributes.
The ajp13 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.
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.
Once the web server has opened a connection to the servlet container,
the connection can be in one of the following states:
Idle No request is being handled over this connection.
Assigned The connecton is handling a specific request.
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 > 0), that is sent in a separate
packet immediately after.
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:
SEND_HEADERS Send a set of headers back to the browser.
SEND_BODY_CHUNK Send a chunk of body data back to the browser.
GET_BODY_CHUNK 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 exa
