You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by pi...@apache.org on 2002/05/20 20:35:28 UTC
cvs commit: jakarta-tomcat-connectors/webapp/docs/images packet1.gif
pier 02/05/20 11:35:28
Modified: webapp/docs warp1.xml
Added: webapp/docs/images packet1.gif
Log:
Added new WARP packet image.
Define datatypes for WARP packet payloads.
Revision Changes Path
1.2 +124 -0 jakarta-tomcat-connectors/webapp/docs/warp1.xml
Index: warp1.xml
===================================================================
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/docs/warp1.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- warp1.xml 13 May 2002 02:33:17 -0000 1.1
+++ warp1.xml 20 May 2002 18:35:28 -0000 1.2
@@ -92,4 +92,128 @@
screaming "Maximum WARP, engage!".
</p>
</section>
+
+ <section title="Packet structure">
+ <description>
+ The Warp 1.0 packet structure
+ </description>
+
+ <p>
+ Compared to previous releases of the WARP protocol, the new packet
+ structure looses its "packet lenght" field. This was done to allow
+ progressive memory allocation during process (we don't require the
+ packet to be fully read before starting to put data in the right
+ places) and because (apart from when raw data was transfered), its
+ value could be easily gathered by the content of the packet itself.
+ </p>
+
+ <p>
+ The new structure of the WARP packet is therefore defined as follows:
+ </p>
+
+ <img src="images/packet1.gif"/>
+
+ <ul>
+ <li>
+ <b>Packet Type</b>: is a unique one-byte value detailing what is
+ contained in the packet's payload.
+ </li>
+ <li>
+ <b>Packet Payload</b>: is a variable-length set of bytes containing
+ the data actually included in this packet. Its length and content
+ vary depending on the type of the packet.
+ </li>
+ </ul>
+ </section>
+
+ <section title="Packet payload">
+ <description>
+ The Warp 1.0 packet payload structure
+ </description>
+
+ <p>
+ Depending on the type of the packet, the payload can contain zero or
+ more fields (each packet type specifies exactly what or where those
+ fields appear in the payload). Here listed are all payload fields
+ recognized by the Warp 1.0 protocol, their field identifier is a
+ reference for the below mentioned packet type descriptions:
+ </p>
+
+ <p>
+ <b>Numeric packet payload fields:</b>
+ </p>
+
+ <ul>
+ <li>
+ <b>signed/unsigned byte</b>: is represented as a 8 bits sequence of
+ data. Its value can range between 0 and 255 decimal if unsigned and
+ between -128 and 127 decimal if signed, with the most significant bit
+ representing the sign. (field identifier: <b>BYTE/UBYTE</b>)
+ </li>
+ <li>
+ <b>signed/unsigned short integer</b>: is represented as a 16 bits
+ sequence of data, encoded in network-byte-order (most significant
+ bytes come first). Its value can range between 0 and 65535 decimal if
+ unsigned and between -32768 and 32767 when signed, with the most
+ significant bit representing the sign (field identifier:
+ <b>SHORT/USHORT</b>).
+ </li>
+ <li>
+ <b>signed/unsigned integer</b>: exactly as for short integers, apart
+ from the fact that it is represented as a sequence of 32 bits,
+ therefore its value can range between -2147483648 and 2147483647
+ decimal when signed or between 0 and 4294967295 when unsigned
+ (field identifier <b>INT/UINT</b>).
+ </li>
+ <li>
+ <b>signed/unsigned long integer</b>: exactly as short and integer, but
+ it is represented as a sequence of 64 bits (you do the maths).
+ (field identifier <b>LONG/ULONG</b>).
+ </li>
+ </ul>
+
+ <p>
+ <b>Variable-length packet payload fields:</b>
+ </p>
+
+ <ul>
+ <li>
+ <b>raw data</b>: a chunk of raw data is transferred following this
+ structure: a USHORT field representing the number of bytes that
+ will be transfered, or if this value is 65535 decimal (0xffff) the
+ "null" sequence of bytes, followed by a serie of bytes (zero or more).
+ (field identifier <b>RAW</b>).
+ </li>
+ <li>
+ <b>generic string</b>: a generic string follows the same structure
+ defined for RAW, but the byte sequence is a US-ASCII encoded
+ representation of a string, as outlined in the HTTP/1.1 specification
+ (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">RFC-2616</a>)
+ for everything but request and response bodies and header values
+ (field identifier <b>STRING</b>).
+ </li>
+ <li>
+ <b>mime string</b>: a mime string is exactly as a generic string,
+ but its byte-representation is supposed to be ISO-8859-1 encoded,
+ and must follow the rules defined by the HTTP/1.1 protocol
+ specification section 2.2 for TEXT (used by header values) referring
+ to <a href="http://www.rfc-editor.org/rfc/rfc2047.txt">RFC-2047</a>
+ (Message Header Extension for Non-ASCII Text). Thus (for example)
+ the string "I love Japan" with the word "Japan" translated in Japanese
+ and encoded in Shift_JIS would be represented as: <b>"I love
+ =?Shift_JIS?q?=e6=97=a5=e6=9c=ac?="</b> (field identifier <b>MIME</b>).
+ </li>
+ </ul>
+
+ <p>
+ For semplicity's sake, this is how one of the three above mentioned
+ variable-length packet payload fields should be transfered (given that
+ the three characters F, o and X have the same value in ISO-8859-1 and
+ US-ASCII, and their hexadecimal value is respectively 0x46, 0x6f and
+ 0x58):
+ </p>
+
+ <img src="images/string.gif"/>
+
+ </section>
</document>
1.1 jakarta-tomcat-connectors/webapp/docs/images/packet1.gif
<<Binary file>>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-tomcat-connectors/webapp/docs/images
packet1.gif
Posted by Pier Fumagalli <pi...@betaversion.org>.
"pier@apache.org" <pi...@apache.org> wrote:
> + <li>
> + <b>generic string</b>: a generic string follows the same structure
> + defined for RAW, but the byte sequence is a US-ASCII encoded
> + representation of a string, as outlined in the HTTP/1.1 specification
> + (<a href="http://www.rfc-editor.org/rfc/rfc2616.txt">RFC-2616</a>)
> + for everything but request and response bodies and header values
> + (field identifier <b>STRING</b>).
> + </li>
> + <li>
> + <b>mime string</b>: a mime string is exactly as a generic string,
> + but its byte-representation is supposed to be ISO-8859-1 encoded,
> + and must follow the rules defined by the HTTP/1.1 protocol
> + specification section 2.2 for TEXT (used by header values) referring
> + to <a href="http://www.rfc-editor.org/rfc/rfc2047.txt">RFC-2047</a>
> + (Message Header Extension for Non-ASCII Text). Thus (for example)
> + the string "I love Japan" with the word "Japan" translated in Japanese
> + and encoded in Shift_JIS would be represented as: <b>"I love
> + =?Shift_JIS?q?=e6=97=a5=e6=9c=ac?="</b> (field identifier <b>MIME</b>).
> + </li>
Folks (of the connector family)... Would like to point you out how things
are supposed to be handled by HTTP... Generic string is all how the first
request line, the first response line and the header names are encoded, mime
string is how header values are encoded...
Since i18n is quite important (at least for my employer) doublecheck that
the connectors behave _like_this_ (as the spec says)...
I'm taking care of WebApp on that part (in the final release of the
protocol, anyway).
Remm, it should be fairly trivial to do the right modifications in Coyote,
also, do we want to add another couple of tests to check out this particular
stuff?
Pier
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>