pier 02/05/12 18:33:58
Modified: webapp/docs style.xsl warp.xml
Log:
Started cleaning up positions and DTD.
Revision Changes Path
1.6 +4 -4 jakarta-tomcat-connectors/webapp/docs/style.xsl
Index: style.xsl
===================================================================
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/docs/style.xsl,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- style.xsl 13 May 2002 00:19:21 -0000 1.5
+++ style.xsl 13 May 2002 01:33:58 -0000 1.6
@@ -224,7 +224,7 @@
</tr>
</table>
</a>
- <xsl:apply-templates select="p|img|screen|todo"/>
+ <xsl:apply-templates select="p|ul|img|screen|todo"/>
<br/>
</xsl:template>
@@ -239,7 +239,7 @@
</xsl:template>
<xsl:template match="p">
- <p class="section"><xsl:apply-templates select="table|ul|b|a|text()"/></p>
+ <p class="section"><xsl:apply-templates select="table|ul|br|b|a|text()"/></p>
</xsl:template>
<xsl:template match="b">
@@ -259,15 +259,15 @@
</p>
</xsl:template>
- <!-- JFC added -->
<xsl:template match="ul">
<ul><xsl:apply-templates select="li"/></ul>
</xsl:template>
<xsl:template match="li">
- <li><xsl:apply-templates select="text()"/></li>
+ <li><xsl:apply-templates select="br|b|a|text()"/></li>
</xsl:template>
+ <!-- JFC added -->
<xsl:template match="table">
<table border="1"><xsl:apply-templates select="tr"/></table>
</xsl:template>
1.3 +97 -109 jakarta-tomcat-connectors/webapp/docs/warp.xml
Index: warp.xml
===================================================================
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/docs/warp.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- warp.xml 13 May 2002 00:22:44 -0000 1.2
+++ warp.xml 13 May 2002 01:33:58 -0000 1.3
@@ -5,130 +5,118 @@
The WARP protocol version 0.10
</description>
- <section title="Data Packet Structure">
+ <section title="Introduction">
<description>
- General packet format.
+ An overview of the WARP protocol
</description>
<p>
- All data sent on the full duplex connection between the client and
- server MUST follow this structure:
+ The WARP protocol was inspired and designed by the great effort made
+ by the Apache JServ team in finding a efficent stream-based protocol
+ to transfer pre-parsed HTTP requests. Much of its structure was derived
+ from the AJPv21 protocol, and has been updated to add few features,
+ and remove its reparsing overhead.
+ </p>
+
+ <p>
+ When thinking about forwarding HTTP requests between a web server (Apache
+ HTTPd) and a servlet container (Apache Tomcat), we must realize that much
+ of the pre-parsing of the HTTP data is already performed by the web-server.
+ Therefore, the scope of the WARP protocol is to minimize the overhead
+ of re-transmitting a pre-parsed HTTP request to the servlet container,
+ encoding data in a way that it's accessible in a very fast and efficent
+ way, without adding a subsequent post-parsing stage.
</p>
-<p>
-<ul>
-<li>
-Data is sent in packets formed by a header describing some info about the
-packet itself followed by a data length and data payload.</li>
-
-<li>
-All packets MUST follow big endian style ("network order").</li>
-
-<li>
-The packet header is always 24 bits long and follow this format:</li>
-
-</ul>
-<ul>
-<li>
-Octet 0 (8 bits) contains the packet type.</li>
-
-<li>
-Octets 1-2 (16 bits) set the length of the data payload carried by the
-packet itself in numbers octets and MAY be zero.</li>
-
-<li>
-If the length of the data payload is more than zero, octets from 3 to (length
-+ 3) contain the payload data or content.</li>
-</ul>
-
-</p>
-<img src="images/packet.gif" alt="The WARP Packet Structure"/>
-
-
-</section>
-
-<section title="Payload">
- <description>
- Payload Structure
- </description>
-
-<p>
-The payload of a packet can be structured in two ways, depending on its
-type: the packet can either contain raw data (such as an HTTP request or
-response body) or a combination of numeric values and strings.
-</p>
-<p>By definition a numeric value is a 32 bit signed integer represented
-in network byte order (the value of 6 decimal would be represented as
- 000000000000000000000000000000000110
-binary (110 preceeded by 29 zeroes).
-</p><p>A string is defined in the following way: the first two octets represent
-the string length as an unsigned 16 bits value. This value indicates the
-number of octets that compose the encoded string. The string is not NULL
-terminated and is encoded following the UTF-8 standard. For example the
-string "fooBar" would be represented as:
-</p>
-<p>
-<table>
-<tr>
-<td13>
-String</td13>
-</tr>
-
-<tr>
-<td>Octet</td>
-
-<td3>1</td3>
-
-<td3>2</td3>
-
-<td>3</td>
-
-<td>4</td>
-
-<td>5</td>
-
-<td>6</td>
-
-<td>7</td>
-
-<td>8</td>
-</tr>
-
-<tr>
-<td>Bits</td>
-
-<td>0</td>
-
-<td>1</td>
-
-<td2>..</td2>
-
-<td>14</td>
-<td>15</td>
+ <p>
+ In addition, the WARP protocol defines a way over which the HTTP server and
+ the servlet container can negotiate their resources (in our case, web
+ applications), maintaining a tight integration between the applications
+ deployed by the servlet container, and their host mapping within the
+ web server.
+ </p>
+ </section>
-<td6>..</td6>
-</tr>
+ <section title="Packet Structure">
+ <description>
+ The structure of a generic WARP packet.
+ </description>
-<tr>
-<td>Content</td>
+ <p>
+ To minimize parsing overhead on both sides (HTTP server and servlet
+ container) the WARP protocol defines a packet structure, which is
+ used to encapsulate all data passed over a reliable full-duplex
+ connection (the WARP connection).
+ </p>
-<td6>110 bin = 6
-dec</td6>
+ <p>
+ Each byte (octet) in a WARP packet MUST be transmitted according to the
+ "network order" (or big endian style), and each packet is composed
+ of the following parts:
+ </p>
-<td>f</td>
+ <ul>
+ <li>
+ An 8 bits long <b>packet type</b> describing the content of the
+ following payload (if any), an operation to perform by the peer,
+ or a reply to an operation requested by the peer.
+ </li>
+ <li>
+ A 16 bits long <b>payload length</b> specifying the length of the
+ payload carried by this packet.
+ </li>
+ <li>
+ A zero-or-more bytes long <b>payload</b>. The length (in bytes) of
+ this part must be specified in the previous two bytes (payload length).
+ </li>
+ </ul>
-<td>o</td>
+ <img src="images/packet.gif" alt="The WARP Packet Structure"/>
-<td>o</td>
+ </section>
-<td>B</td>
+ <section title="Payload">
+ <description>
+ Payload Structure
+ </description>
-<td>a</td>
+ <p>
+ The payload of a packet can be structured in two ways, depending on its
+ type: the packet can either contain raw data (such as an HTTP request or
+ response body) or a combination of numeric values and strings.
+ </p>
+
+ <p>
+ By definition a numeric value is a 32 bit signed integer represented
+ in network byte order (the value of 6 decimal would be represented as
+ 000000000000000000000000000000000110 binary (110 preceeded by 29
+ zeroes).
+ </p>
-<td>r</td>
-</tr>
-</table>
-</p>
+ <p>
+ A string is somehow more complex, and it is defined in the following way:
+ </p>
+
+ <ul>
+ <li>
+ The first two octets represent the string length as an unsigned 16 bits
+ value. The 0x0 and 0x0ffff values (namely the sequence of all zero bits
+ and the sequence of all one bits) have a special meaning.
+ </li>
+ <li>
+ If the string length (first two octets) is not 0x0 or 0x0ffff, a sequence
+ of bytes follow, as long as the number of bytes specified in length.
+ The bytes in this field are the UTF-8 representation of the string.
+ </li>
+ <li>
+ If length is 0x0, the string is assumed to be the empty string.
+ </li>
+ <li>
+ If length is 0x0ffff, the string is assumed to be the null string.
+ </li>
+ </ul>
+
+ <img src="images/string.gif" alt="The "FooX" string"/>
</section>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
