Re: Bug(?) and suggested solution for chunked transfer-encoding POSTrequest
Remy Maucherat wrote: Adrian Sampaleanu wrote: We are having a problem with Catalina 4.1.12 (I believe we also had issues with previous versions, but can't say for sure) with respect to how POSTed requests are handled if the transfer encoding is chunked. It seems that request parameters in the content are not processed in this case. This is not legal. In HTTP/1.1, FORM encoded data of a POST must have a content-length. You can do the parsing yourself, of course. Rémy See RFC2616, Section 4.4. An excerpt: Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non- identity transfer-coding, the Content-Length MUST be ignored. In looking through RFC2616, I didn't see any special case for POST requests with FORM encoding that either required the use of Content-Length (thereby prohibiting the use of Transfer-Encoding: chunked) or vice versa. If I missed it or if its in a different RFC please post a reference. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Possible bug in RequestDispatcher?
I looked into this a little further. I think the resource the URL points to has a Content-Length of 234 bytes. The Filter uses RequestDispatcher.forward() to return a document that is longer, and that document is getting truncated at about 234 bytes. Could TC be setting the Content-Length header based on the originally requested document but returning the data from the forwarded one? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Ryan Hoegg wrote: OK, that clarifies things a little bit. If the problem isn't with RequestDispatcher, I am even more puzzled. I have narrowed the problem down to a particular use case: I have a single filter that calls getFilterContext().getServletContext().getRequestDispatcher(/WEB-INF/templates/form.html).forward(request, response) in the absence of a particular session variable on the request. This filter is mapped to /* and I have a single servlet mapped to /Display Pointing my browser at /webapp/Display : things work as expected. Pointing my browser at /webapp/ : things work as expected Pointing my browser at /webapp/staticfile.html : problem. View Source in my browser shows this: - !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html head title/title /head body form action=j_security_check method=POST pU -- That is the beginning of the html file I am trying to forward() to. It seems like my HttpServletResponse's OutputStream is getting closed prematurely in the exact same place in my forwarded file. So what could it be?! -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Craig R. McClanahan wrote: In Servlet 2.3 (i.e. Tomcat 4.x), filters are *not* invoked on request dispatcher calls -- only on the original request. In Servlet 2.4 (i.e. Tomcat 5.x) you can optionally configure which filters should be used on forwards, includes, or both, with suitable settings in web.xml. Craig -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Possible bug in RequestDispatcher?
Hi, Before I post a bug report, I wanted to run a peculiar situation by the experts. I am creating some filters that verify that certain variables are in the session before allowing access to any page in my site. There are currently two of them, and each forward the request to a form if a particular session variable is not set and if this is not the form submission. They are using ((HttpServletRequest) request).getRequestDispatcher(/path/to/form1.html).forward(request, response) to accomplish this. Something is broken, and if it's in my code I am missing it. I have these filters mapped to /* and here is the peculiar behavior: 1. If I point my browser at /, I get the desired HTML page. 2. If I point at a servlet I have mapped, I get what looks like an HTML template page. 3. If I point at a static HTML file I have in the / I get a good chunk of the beginning of the HTML page and that's it. My web.xml is simpler than simple, I described it above except for the single servlet mapping. (/Display) I appreciate any insights you can provide! -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Possible bug in RequestDispatcher?
OK, that clarifies things a little bit. If the problem isn't with RequestDispatcher, I am even more puzzled. I have narrowed the problem down to a particular use case: I have a single filter that calls getFilterContext().getServletContext().getRequestDispatcher(/WEB-INF/templates/form.html).forward(request, response) in the absence of a particular session variable on the request. This filter is mapped to /* and I have a single servlet mapped to /Display Pointing my browser at /webapp/Display : things work as expected. Pointing my browser at /webapp/ : things work as expected Pointing my browser at /webapp/staticfile.html : problem. View Source in my browser shows this: - !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html head title/title /head body form action=j_security_check method=POST pU -- That is the beginning of the html file I am trying to forward() to. It seems like my HttpServletResponse's OutputStream is getting closed prematurely in the exact same place in my forwarded file. So what could it be?! -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net Craig R. McClanahan wrote: In Servlet 2.3 (i.e. Tomcat 4.x), filters are *not* invoked on request dispatcher calls -- only on the original request. In Servlet 2.4 (i.e. Tomcat 5.x) you can optionally configure which filters should be used on forwards, includes, or both, with suitable settings in web.xml. Craig -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Tomcat scalability
One good rule of thumb is not to solve problems that don't exist. Your first task is to set up a server and hit it with something a good 20%-50% more demanding than your expected load. There exist several automated tools to do this. One is JMeter at http://jakarta.apache.org/jmeter/index.html . Then, have a look at your actual performance and work on the bottlenecks that arise. If your application is spending most of its time waiting for database results, cache them. If your application is spending most of its time creating and destroying objects, consider pooling. If your app is choking on serving up 1600 images a second, use a web server such as Apache in front of Tomcat. That will help with static requests (images, static HTML) even with a single Tomcat server doing the servlet work. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net [EMAIL PROTECTED] wrote: That's a tough question to answer, and pretty much the only way you're going to be able to tell is to try it. Here's a few suggestions of things to think about: The first question you might want to ask is can your database handle 1600 transactions per second? If not (and even if it can) you may want to consider whether some kind of caching could help you if the data is largely static. This could be caching of the data itself, or something as simple as caching the pages themselves, with some scheme to flush the cache if the data changes. If your data is not very static, then this wouldn't be as helpful of course. If it's possible on the OS you are using, I'd be tempted to run 4 copies of Tomcat, and dedicate a processor to each one. It's a lot harder to write code that will run reliably on a MP machine than on a SP one, and it seems that Tomcat has a few issues in that regard. Also, remember, it's unlikely you'll ever have that many threads open at once - if you are actually handling 1600 requests/second then each request is, on average, taking less than a millisecond to complete, so you won't have too many overlapping requests. If you can work out how long it takes to process one request, then you'll have a best-case scenario of how many you can handle. In practice, it will be less of course, due to overhead in handling multiple requests at once. -- Rob 1. For a project my company is working on we have transactions requirements of 1600 transactions per second. The transactions consists of processing a servlet in Tomcat, doing a database call and then displaying the results to the user so the effective number of transactions Tomcat has to process is actually greater than 1600. Can Tomcat cope with 1600 requests in a second(a 4 processor Sunfire machine will be used)? Based upon our current application architecture(our java application has tomcat running inside it), 1600 request per second means we may have 1600 threads open simultaneously. 2. From one article I read at linux journal, Tomcat 3 didn't scale very well with multiple processors because of JVM issues. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Catalina Ant tasks
Hi, Am I missing something or do we not have Ant tasks for the functionality available through the /admin application? I have an itch, so if not I will be willing to contribute some code. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Form Based Authentication, getting login and password
Hi, I am new to the list, so nice to meet you. I found this thread in the archives while researching a way to do something similar. I want to implement an authenticator that uses information in the session to augment the authentication. I have looked into creating a subclass of FormAuthenticator and it seems fairly straightforward. My plan is to override the authenticate() method and: 1. Check if the session is properly initialized (not sure how yet), and if not do something similar to the login form submission piece to collect prerequisite session info. 2. Build the username from the one submitted on the login form and from arbitrary session variables. 3. Hand off the rest of the authentication to FormAuthenticator for Realm based authentication. This strategy would also allow me to build in 3 strikes and you're out functionality as I am inspecting the session before sending the authentication request to the realm. Questions: 1. Is the entire idea wrongheaded for some reason that I am missing? 2. Any gotchas someone would like to point out for me? 3. authenticate() is an awfully long method. Would anyone object to breaking it down into several protected method calls so that I can just override those and leave the rest up to FormAuthenticator? Currently I have to copy a lot of code into my subclass. I will be happy to submit my changes upstream. I have worked a little with the Jakarta community and know the routine... you guys haven't switched to Scarab yet have you? -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
