There are two bugs in org.apache.catalina.connector.InputBuffer: 1) If you send a POST with 8K in the body then the optimizedWrite flag in CharChunk prevents the input data from being read into the CharChunk. This only happens at and after the second request on an input processor, because the optimizedWrite flag ist being set to true when recycling the InputBuffer after the first request. 2) After fixing that, you can more easily see another bug: realReadChars always reads the full ByteChunk buffer size and then tries to convert it into the CharChunk. There is a corner case, where CharChunk has a limit just a little too small, to be able to do that. This is not about making CharChunk much bigger. I can give more precise details, but the patch might be self-explaining (it is very short). I attach - a patch - a JSP and a perl script to easily reproduce the problem. Problem 1) can be reprodiced by setting CHUNK in the script to 8192, problem 2 (after fixing 1) by setting it slightly bigger than 8192, e.g. 8300.
Created attachment 17478 [details] Patch for InputBuffer fixing 1) and 2)
Created attachment 17479 [details] Test JSP Test JSP to be called by the next attachment
Created attachment 17480 [details] Test Client perl script Client side script which posts data to the test JSP to reproduce both bugs.
By the way: the same problem (and the same fix) apply to the 5.0 branch.
I was at our customers side today. The problem is always reproducible with the ajp connector. On his system, I can not reproduce with HTTP connector. But from the code in InputBuffer it's clear, that the occurence of the bug only depends on the amount of data received on the socket, when the buffer loads new data. I'm pretty confident, that the patch also fixes bugs 34829, 28959, 27447, and 24897. I know, that CoyoteReader/InputBuffer/(Byte|Char)Chunk are difficult to understand and noone wants to touch them. But I instrumented the classes to exactly find out what's happening, and if Remy (or whoever is willing to dig into it) likes more explanation of the patch please ask. At the customer's installation his problem was fixed with the patch.
(In reply to comment #5) > I was at our customers side today. The problem is always reproducible with the > ajp connector. On his system, I can not reproduce with HTTP connector. But from > the code in InputBuffer it's clear, that the occurence of the bug only depends > on the amount of data received on the socket, when the buffer loads new data. By default, the HTTP connector only reads 4K at a time, so serendipitously this bug doesn't show itself. The patch has been committed to the SVN trunk, and will appear in 5.5.16.
*** Bug 38836 has been marked as a duplicate of this bug. ***
thi issue still occurs with tomcat 5.5.28. Could you please let me know, how to apply this patch to 5.5.28?
This is very unlikely the same problem. Bugzilla is not a support form. Please post your problem description to the Tomcat users list. Regards, Rainer
Thanks for your response Jung. We have an environment using HTTP connector. The issue does not occur, other environment using AJP connector. In code we are using BufferedReader in = request.getReader(); When a request is sent on AJP connector environment, the above code reads only 8192 length, not whole. But if a request is sent on HTTP connector environment, the same method reads whole data. do you have any idea.. Please help. The Tomcat version same in the both of the environments above.
Please discuss this on the Tomcat users list, see http://tomcat.apache.org/lists.html Thank you.