tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From p...@apache.org
Subject cvs commit: jakarta-tomcat-connectors/webapp/docs style.xsl warp.xml
Date Mon, 13 May 2002 01:33:58 GMT
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 &#34;FooX&#34; string"/>
   
   </section>
   
  
  
  

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message