[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: Tomcat looses POST parameters
From:       M4N - Arjan Tijms <arjan.tijms () mbuyu ! nl>
Date:       2007-08-30 16:47:34
Message-ID: 46D6F4A6.1000807 () mbuyu ! nl
[Download RAW message or body]

Hi,

M4N - Arjan Tijms wrote:

> The problem I'm encountering is that for a percentage of the POST 
> requests, Tomcat seems to loose all parameters. Our application uses a 
> filter that logs the (first few characters of) post parameters.


To follow up on this issue, I think that I have probably found the cause 
of this issue. In the AJP/1.3 connector configuration in server.xml, the 
connectionTimeout had been set to a very low value (200). In the 
catalina.[date].log this resulted in entries like:


Aug 29, 2007 4:27:21 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31
Aug 29, 2007 4:27:23 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31
Aug 29, 2007 4:27:25 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31
Aug 29, 2007 4:27:26 PM org.apache.jk.common.HandlerRequest invoke
INFO: Unknown message 31


Except for message "31", there were also entries for Unknown message 8, 
1, 19, 20, 22, 0, 29, 11 and 15, although 31 was the most common. I 
missed these messages earlier (which is stupid of me, I know). I 
compared the time stamps of these messages with those of the "empty 
posts" in the other log file and found out they matched exactly or 
almost exactly.

Looking up the code of HandlerRequest it appears to switch on a byte, 
defined in org.apache.jk.common.AjpConstants. It actually switches on a 
subset of these. The default action is to print the Unknown message line 
and continue, which happens for the numbers I mentioned above.

Perhaps the connector is closing the connection early, but tomcat 
somehow isn't signalled about that event and switches on a random byte 
from the message the AJP connector was sending. Anyway, the result is 
that the post request continues to be processed, but with missing 
request parameters.

Setting the timeout value too low is of course our fault, but perhaps it 
would be better if Tomcat could just abort the request and throw some 
exception?

Kind regards,
Arjan Tijms





-- 
It's a cult. If you've coded for any length of time, you've run across someone from \
this warped brotherhood. Their creed: if you can write complicated code, you must be \
good.


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]