tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31523] - Request parameters are not always passed to HttpServlet.service
Date Mon, 04 Oct 2004 15:56:52 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31523>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31523

Request parameters are not always passed to HttpServlet.service





------- Additional Comments From emond@emaxx.nl  2004-10-04 15:56 -------
I've tried running Tomcat with the security manager enabled (with a grant all 
in the policy file). This brought up some worrying facts. I will first give a 
little info on the way our application is working. 
 
As I've said before, we are using Cocoon Forms with the underlying flow to 
chain the forms. However the default flow (using javascript) was not powerful 
enough. The concept of a continuation framework, is that it simulates a thread, 
which is suspended when a page is shown to the user, and continued when the 
user submits the form. To be able to build more robust applications, we decided 
to use a real thread as the flow, which is locked (with wait) and notified. It 
is impossible for this thread to run simultaneously with the servlet thread. 
When the first is running, the second is locked and vice versa. However I've 
discovered, that even though these threads don't run at the same time, either 
Cocoon or Tomcat is affected. They seem to rely on the thread currently 
executing. 
 
When Tomcat is running with the security manager enabled, the creation of the 
form hierarchy triggers a NullPointerException 
at  org.apache.coyote.tomcat5.CoyoteRequestFacade. 
        getQueryString(CoyoteRequestFacade.java:481). 
 
I've managed to get around this, by creating an Expression that executes the 
malicious method. This Expression is then passed to the servlet thread, which 
executes it from its own context and passes the result back to the flow thread. 
Still no two threads will ever be running at the same time, but this time the 
method succeeds. Is this expected behaviour? 
 
I've looked at the postparam application. If the bug is in Tomcat, this should 
trigger it, however it might be very hard to hit it, because you might have to 
resubmit over 100 times. What makes it even more complicated is that we 
discovered that we can avoid the problem, by printing lots of debug to stdout. 
This shows how sensitive the timing is. 
 
At this moment we are considering to drop the flow thread and emulate it with a 
bytecode interpreter. If it is correct that Tomcat cannot handle multiple 
threads inside a servlet, even when they cannot run concurrently, then this 
might very well be what triggers the problem. In that case, I apologise for the 
trouble and I will definitely switch to a bytecode interpreter that runs in the 
servlet thread.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message