You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by sc...@apache.org on 2014/12/30 20:58:08 UTC
svn commit: r1648589 - /tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml
Author: schultz
Date: Tue Dec 30 19:58:08 2014
New Revision: 1648589
URL: http://svn.apache.org/r1648589
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48460
- Clarified staggeringly incorrect statement about byte-order
- Fixed bad hex mental math
- Unwound logical confusion about true versus false values and their meanings
Modified:
tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml
Modified: tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml
URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml?rev=1648589&r1=1648588&r2=1648589&view=diff
==============================================================================
--- tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml (original)
+++ tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml Tue Dec 30 19:58:08 2014
@@ -145,13 +145,11 @@ Response Packet Structures below for det
<p>
There is a bit of an XDR heritage to this protocol, but it differs in
lots of ways (no 4 byte alignment, for example).
-</p><p>
-Byte order: I am not clear about the endian-ness of the individual
-bytes. I'm guessing the bytes are little-endian, because that's what XDR
-specifies, and I'm guessing that sys/socket library is magically making
-that so (on the C side). If anyone with a better knowledge of socket calls
-can step in, that would be great.
-</p><p>
+</p>
+<p>
+ AJP13 uses network byte order for all data types.
+</p>
+<p>
There are four data types in the protocol: bytes, booleans, integers and
strings.
@@ -489,7 +487,7 @@ additional methods, even if they are not
two-byte integer is the length of a string, which is then read in.
</p><p>
This works on the assumption that no header names will have length
- greater than 0x9999 (==0xA000 - 1), which is perfectly reasonable, though
+ greater than 0x9FFF (==0xA000 - 1), which is perfectly reasonable, though
somewhat arbitrary. (If you, like me, started to think about the cookie
spec here, and about how long headers can get, fear not -- this limit is
on header <b>names</b> not header <b>values</b>. It seems unlikely that
@@ -509,7 +507,7 @@ additional methods, even if they are not
The attributes prefixed with a <code>?</code>
(e.g. <code>?context</code>) are all optional. For each, there is a
single byte code to indicate the type of attribute, and then a string to
- give its value. They can be sent in any order (thogh the C code always
+ give its value. 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:
@@ -654,8 +652,8 @@ Details:
<p>
Signals the end of this request-handling cycle. If the
<code>reuse</code> flag is true (==1), this TCP connection can now be used to
- handle new incoming requests. If <code>reuse</code> is false (anything
- other than 1 in the actual C code), the connection should be closed.
+ handle new incoming requests. If <code>reuse</code> is true (anything
+ other than 0 in the actual C code), the connection should be closed.
</p>
</subsection>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1648589 - /tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Chris,
Am 30.12.2014 um 20:58 schrieb schultz@apache.org:
> Author: schultz
> Date: Tue Dec 30 19:58:08 2014
> New Revision: 1648589
>
> URL: http://svn.apache.org/r1648589
> Log:
> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48460
> - Clarified staggeringly incorrect statement about byte-order
> - Fixed bad hex mental math
> - Unwound logical confusion about true versus false values and their meanings
>
>
> Modified:
> tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml
>
> Modified: tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml
> URL: http://svn.apache.org/viewvc/tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml?rev=1648589&r1=1648588&r2=1648589&view=diff
> ==============================================================================
> --- tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml (original)
> +++ tomcat/jk/trunk/xdocs/ajp/ajpv13a.xml Tue Dec 30 19:58:08 2014
...
> @@ -654,8 +652,8 @@ Details:
> <p>
> Signals the end of this request-handling cycle. If the
> <code>reuse</code> flag is true (==1), this TCP connection can now be used to
> - handle new incoming requests. If <code>reuse</code> is false (anything
> - other than 1 in the actual C code), the connection should be closed.
> + handle new incoming requests. If <code>reuse</code> is true (anything
> + other than 0 in the actual C code), the connection should be closed.
> </p>
> </subsection>
Are you sure about that change? It doesn't sound logical and also is not
how I interprete BZ 48460. To me the comment in BZ indicates, that the
meaning of true (reuse TCP) and false (close connection) was OK and
should not be changed, but the definition of true should be "anything
other than 0 in the actual C code" instead of "==1" and false would be
"==0" instead of "anything other than 1 in the actual C code". I haven't
checked the impl though.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org