https://issues.apache.org/bugzilla/show_bug.cgi?id=49413
Rainer Jung <rainer.j...@kippdata.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #1 from Rainer Jung <rainer.j...@kippdata.de> 2010-06-09 07:53:41
EDT ---
I think you hit the following JBoss bug. If you have a support contract with
them, please raise an issue there. You should mention, which AJP connector in
JBoss you are using:
Since I will refer to those types, as a reminder here's the list of AJP
packet types used by the backend:
3 Send Body Chunk
4 Send Headers
5 End Response
6 Get Body Chunk
9 CPong Reply
What happens is, that after mod_jk sends the request, JBoss responds, sending
type "3" packets containing the response data, and after the final response
packet it send a type "5" packet with the reuse bit set, which tells mod_jk
that the response is finished.
So far everything is fine.
Now very shortly after that, the backend sends another type "3" packet with
data of size "0" over the same connection. That's the packet that is not
allowed and breaks the protocol. mod_jk doesn't consume that packet, because
packet type "5" ends response processing. The packet stays in the connection
buffer. I think that happens only for some JBos AJP connectors, but I don't
know which of them.
When the next request arrives, mod_jk sends the request headers and expects a
type "6" packet from the backend. Instead it reads the old type "3" packet
still in the buffer and throws an error because of a protocol corruption.
To sum up: the problem is JBoss sending an empty type "3" packet after
the response is finished. It doesn't happen for all requests, but it
happens quite often. It is not unlikely that the error is triggered by
strange webapp behaviour, but the webapp should not be able to corrupt
the AJP 13 protocol.
Other users exhibit the same probem when enabling cping/cpong. Then the
erroneous type "3" packet is detected when waiting for the cping answer of type
"9" and triggers again a failure. That failure also leads to closing the
connection, but might be handled a bit faster and more transparent from the
point of view of the browser and application.
I'll mark this as invalid, because we made mod_jk stricter on protocol checks
for security reasons. Feel free to reopen if you find any information that
contradicts my explanation. Please let us know how JBoss responds.
Rainer
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
