You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by da...@apache.org on 2001/01/28 21:51:45 UTC
cvs commit: jakarta-tomcat/src/doc AJPv13.html
danmil 01/01/28 12:51:45
Modified: src/doc AJPv13.html
Log:
Adding support for WEBDAV methods to Ajp13.
Contributed by Keith Wannamaker (Keith@Wannamaker.org).
Also, adding documentation for what is done if the servlet container
requests more body information than the web server can supply.
Revision Changes Path
1.2 +20 -9 jakarta-tomcat/src/doc/AJPv13.html
Index: AJPv13.html
===================================================================
RCS file: /home/cvs/jakarta-tomcat/src/doc/AJPv13.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- AJPv13.html 2000/12/05 06:32:13 1.1
+++ AJPv13.html 2001/01/28 20:51:45 1.2
@@ -26,8 +26,8 @@
don't know why certain design decisions were made. Where I was able, I've
offered some possible justifications for certain choices, but those are
only my guesses. In general, the C code which Shachor wrote is very clean
-and comprehensible (if almost totally undocumented). The Java code is
-pretty much a mess.
+and comprehensible (if almost totally undocumented). I've cleaned up the
+Java code, and I think it's reasonably readable.
<P>
<B>Design Goals</B>
@@ -342,13 +342,20 @@
<DD>The HTTP method, encoded as a single byte:
<P>
<PRE>
-OPTIONS 1
-GET 2
-HEAD 3
-POST 4
-PUT 5
-DELETE 6
-TRACE 7
+OPTIONS 1
+GET 2
+HEAD 3
+POST 4
+PUT 5
+DELETE 6
+TRACE 7
+PROPFIND 8
+PROPPATCH 9
+MKCOL 10
+COPY 11
+MOVE 12
+LOCK 13
+UNLOCK 14
</PRE>
<P>
</DD>
@@ -545,6 +552,10 @@
<CODE>request_length</CODE>, the maximum send body size (XXX), and the
number of bytes actually left to send from the request body.<P>
+ 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, whch is a body packet with a payload length of 0.
+
</DL>
<P>