Here's what I believe to be the relevant worker thread stack trace:
Code:
"http-8080-Processor100" daemon prio=1 tid=0xa37112d8 nid=0x1041 runnable [0xa0aa6000..0xa0aa6fb0]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:737)
at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:398)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:827)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Note that it's still in the tomcat-processing-the-HTTP-request phase; it hasn't even hit any Zimbra code. The most likely culprit that I can think of is that the Content-Length on your request is incorrect.
Note that if you're using Zimbra 4.0 or later, I
believe that
zmprov without the
-l switch does SOAP requests in XML getting back XML responses. If
zmprov works and your stuff doesn't, it's almost certainly your request at fault...