From fe39ffb8b90ae4e002ed73fe98617cd590abb467 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 08:33:50 +0200 Subject: Adding upstream version 2.4.56. Signed-off-by: Daniel Baumann --- docs/manual/mod/mod_proxy_ajp.html.en | 639 ++++++++++++++++++++++++++++++++++ 1 file changed, 639 insertions(+) create mode 100644 docs/manual/mod/mod_proxy_ajp.html.en (limited to 'docs/manual/mod/mod_proxy_ajp.html.en') diff --git a/docs/manual/mod/mod_proxy_ajp.html.en b/docs/manual/mod/mod_proxy_ajp.html.en new file mode 100644 index 0000000..1d8cb01 --- /dev/null +++ b/docs/manual/mod/mod_proxy_ajp.html.en @@ -0,0 +1,639 @@ + + + + + +mod_proxy_ajp - Apache HTTP Server Version 2.4 + + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+ +
+

Apache Module mod_proxy_ajp

+
+

Available Languages:  en  | + fr  | + ja 

+
+ + + + +
Description:AJP support module for +mod_proxy
Status:Extension
Module Identifier:proxy_ajp_module
Source File:mod_proxy_ajp.c
Compatibility:Available in version 2.1 and later
+

Summary

+ +

This module requires the service of mod_proxy. It provides support for the + Apache JServ Protocol version 1.3 (hereafter + AJP13).

+ +

Thus, in order to get the ability of handling AJP13 + protocol, mod_proxy and + mod_proxy_ajp have to be present in the server.

+ +

Warning

+

Do not enable proxying until you have secured your server. Open proxy + servers are dangerous both to your network and to the Internet at + large.

+
+
+ +
top
+
+

Usage

+

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 ajp:// prefix:

+ +

Simple Reverse Proxy

ProxyPass "/app" "ajp://backend.example.com:8009/app"
+
+ +

Options such as the secret option of Tomcat (required by + default since Tomcat 8.5.51 and 9.0.31) can just be added as a separate + parameter at the end of ProxyPass + or BalancerMember. This parameter + is available in Apache HTTP Server 2.4.42 and later:

+

Simple Reverse Proxy with secret option

ProxyPass "/app" "ajp://backend.example.com:8009/app" secret=YOUR_AJP_SECRET
+
+ +

Balancers may also be used:

+

Balancer Reverse Proxy

<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"
+
+ +

Note that usually no + ProxyPassReverse + 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.

+ +

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 ajp:// URL), for + example:

+

Rewriting Proxied Path

ProxyPass "/apps/foo" "ajp://backend.example.com:8009/foo"
+ProxyPassReverse "/apps/foo" "http://www.example.com/foo"
+
+

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. +

+
top
+
+

Environment Variables

+

Environment variables whose names have the prefix AJP_ + are forwarded to the origin server as AJP request attributes + (with the AJP_ prefix removed from the name of the key).

+
top
+
+

Overview of the protocol

+

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 connection is handling a specific request.
    • +
+

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 (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 example). (Note: this is unrelated to + HTTP chunked transfer).
    • +
  • END_RESPONSE
    Finish the request-handling cycle.
    • +
+

Each message is accompanied by a differently formatted packet of data. + See Response Packet Structures below for details.

+
top
+
+

Basic Packet Structure

+

There is a bit of an XDR heritage to this protocol, but it differs + in lots of ways (no 4 byte alignment, for example).

+

AJP13 uses network byte order for all data types.

+

There are four data types in the protocol: bytes, booleans, + integers and strings.

+
+
Byte
A single byte.
+
Boolean
+
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.
+
Integer
+
A number in the range of 0 to 2^16 (32768). Stored in + 2 bytes with the high-order byte first.
+
String
+
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 + not include the trailing '\0' -- it is like + strlen. 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.
+
+ +

Packet Size

+

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.

+ +

Packet Headers

+

Packets sent from the server to the container begin with + 0x1234. Packets sent from the container to the server + begin with AB (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.

+ + + + + + + + + + + + + + + + + + + + +
Packet Format (Server->Container)
Byte01234...(n+3)
Contents0x120x34Data Length (n)Data
+ + + + + + + + + + + + + + + + + + + + +
Packet Format (Container->Server)
Byte01234...(n+3)
ContentsABData Length (n)Data
+

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.

+

The web server can send the following messages to the servlet + container:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeType of PacketMeaning
2Forward RequestBegin the request-processing cycle with the following data
7ShutdownThe web server asks the container to shut itself down.
8PingThe web server asks the container to take control + (secure login phase).
10CPingThe web server asks the container to respond quickly with a CPong. +
noneDataSize (2 bytes) and corresponding body data.
+

To ensure some basic security, the container will only actually do the + Shutdown if the request comes from the same machine on which + it's hosted.

+

The first Data packet is send immediately after the + Forward Request by the web server.

+

The servlet container can send the following types of messages to the + webserver:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CodeType of PacketMeaning
3Send Body ChunkSend a chunk of the body from the servlet container to the web + server (and presumably, onto the browser).
4Send HeadersSend the response headers from the servlet container to the web + server (and presumably, onto the browser).
5End ResponseMarks the end of the response (and thus the request-handling cycle). +
6Get Body ChunkGet further data from the request if it hasn't all been + transferred yet.
9CPong ReplyThe reply to a CPing request
+

Each of the above messages has a different internal structure, detailed + below.

+ +
top
+
+

Request Packet Structure

+

For messages from the server to the container of type + Forward Request:

+ 
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
+

The request_headers have the following structure: + 

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)
+

The attributes are optional and have the following + structure:

+ 
attribute_name := sc_a_name | (sc_a_req_attribute string)
+
+attribute_value := (string)
+

Not that the all-important header is content-length, + because it determines whether or not the container looks for another + packet immediately.

+

Detailed description of the elements of Forward Request +

+

Request prefix

+

For all requests, this will be 2. See above for details on other Prefix + codes.

+ +

Method

+

The HTTP method, encoded as a single byte:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Command NameCode
OPTIONS1
GET2
HEAD3
POST4
PUT5
DELETE6
TRACE7
PROPFIND8
PROPPATCH9
MKCOL10
COPY11
MOVE12
LOCK13
UNLOCK14
ACL15
REPORT16
VERSION-CONTROL17
CHECKIN18
CHECKOUT19
UNCHECKOUT20
SEARCH21
MKWORKSPACE22
UPDATE23
LABEL24
MERGE25
BASELINE_CONTROL26
MKACTIVITY27
+

Later version of ajp13, will transport + additional methods, even if they are not in this list.

+ +

protocol, req_uri, remote_addr, remote_host, server_name, + server_port, is_ssl

+

These are all fairly self-explanatory. Each of these is required, and + will be sent for every request.

+ +

Headers

+

The structure of request_headers is the following: + First, the number of headers num_headers is encoded. + Then, a series of header name req_header_name / value + req_header_value 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 sc_req_header_nameand their codes + is as follows (all are case-sensitive):

+ + + + + + + + + + + + + + + + + + + +
NameCode valueCode name
accept0xA001SC_REQ_ACCEPT
accept-charset0xA002SC_REQ_ACCEPT_CHARSET +
accept-encoding0xA003SC_REQ_ACCEPT_ENCODING +
accept-language0xA004SC_REQ_ACCEPT_LANGUAGE +
authorization0xA005SC_REQ_AUTHORIZATION
connection0xA006SC_REQ_CONNECTION
content-type0xA007SC_REQ_CONTENT_TYPE
content-length0xA008SC_REQ_CONTENT_LENGTH
cookie0xA009SC_REQ_COOKIE
cookie20xA00ASC_REQ_COOKIE2
host0xA00BSC_REQ_HOST
pragma0xA00CSC_REQ_PRAGMA
referer0xA00DSC_REQ_REFERER
user-agent0xA00ESC_REQ_USER_AGENT
+

The Java code that reads this grabs the first two-byte integer and if + it sees an '0xA0' 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.

+

This works on the assumption that no header names will have length + greater than 0x9FFF (==0xA000 - 1), which is perfectly + reasonable, though somewhat arbitrary.

+

Note:

+ The content-length 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. +
+ +

Attributes

+

The attributes prefixed with a ? + (e.g. ?context) 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:

+ + + + + + + + + + + + + + + +
InformationCode ValueType Of ValueNote
?context0x01-Not currently implemented +
?servlet_path0x02-Not currently implemented +
?remote_user0x03String
?auth_type0x04String
?query_string0x05String
?jvm_route0x06String
?ssl_cert0x07String
?ssl_cipher0x08String
?ssl_session0x09String
?req_attribute0x0AStringName (the name of the + attribute follows)
?ssl_key_size0x0BInteger
?secret0x0CStringSupported since 2.4.42
are_done0xFF-request_terminator
+

The context and servlet_path 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.

+

The remote_user and auth_type 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).

+

The query_string, ssl_cert, + ssl_cipher, ssl_session and + ssl_key_size refer to the + corresponding pieces of HTTP and HTTPS.

+

The jvm_route, is used to support sticky + sessions -- associating a user's sesson with a particular Tomcat instance + in the presence of multiple, load-balancing servers.

+

The secret is sent when the secret=secret_keyword + parameter is used in + ProxyPass or + BalancerMember directives. + The backend needs to support secret and the values must match. + request.secret or requiredSecret are documented in the AJP + configuration of the Apache Tomcat.

+

Beyond this list of basic attributes, any number of other attributes + can be sent via the req_attribute 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.

+

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.

+ +
top
+
+

Response Packet Structure

+

for messages which the container can send back to the server.

+ 
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)
+

Details:

+

Send Body Chunk

+

The chunk is basically binary data, and is sent directly back to the + browser.

+ +

Send Headers

+

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 header_encoding above + for details about how the codes are distinguished from the strings.
+ The codes for common headers are:

+ + + + + + + + + + + + + +
NameCode value
Content-Type0xA001
Content-Language0xA002
Content-Length0xA003
Date0xA004
Last-Modified0xA005
Location0xA006
Set-Cookie0xA007
Set-Cookie20xA008
Servlet-Engine0xA009
Status0xA00A
WWW-Authenticate0xA00B
+

After the code or the string header name, the header value is + immediately encoded.

+ +

End Response

+

Signals the end of this request-handling cycle. If the + reuse flag is true (anything other than 0 in the actual + C code), this TCP connection can now be used to handle new incoming + requests. If reuse is false (==0), the connection should + be closed.

+ +

Get Body Chunk

+

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 request_length, the maximum send + body size (8186 (8 Kbytes - 6)), and the number of bytes + actually left to send from the request body.
+ 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)

+ +
+
+
+

Available Languages:  en  | + fr  | + ja 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3