I submitted a patch on the review board https://reviews.apache.org/r/595/diff/#index_header to improve the error message If the AJP packetSize is not large enough. As is: org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler process SEVERE: Error reading request, ignored java.lang.StringIndexOutOfBoundsException: String index out of range: 13628 at java.lang.String.checkBounds(String.java:401) at java.lang.String.<init>(String.java:442) at org.apache.tomcat.util.buf.ByteChunk.toStringInternal(ByteChunk.java:497) at org.apache.tomcat.util.buf.StringCache.toString(StringCache.java:216) at org.apache.tomcat.util.buf.ByteChunk.toString(ByteChunk.java:490) at org.apache.tomcat.util.buf.MessageBytes.toString(MessageBytes.java:213) at org.apache.coyote.RequestInfo.updateCounters(RequestInfo.java:156) at org.apache.coyote.Request.updateCounters(Request.java:518) at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:455) at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:384) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1665) at java.lang.Thread.run(Thread.java:662) [Fri Apr 08 17:23:44 2011] [error] ajp_read_header: ajp_ilink_receive failed [Fri Apr 08 17:23:44 2011] [error] (120006)APR does not understand this error code: proxy: read response failed from 127.0.0.1:8003 (127.0.0.1) [Fri Apr 08 17:23:44 2011] [error] (104)Connection reset by peer: ajp_ilink_receive() can't receive header
Putting a try/catch around the symptom is not the best way to handle this. It should be possible to identify when packet length > buffer, log a suitable message at an appropriate level, ensure a 400 is recorded in the access log (probably only possible in Tomcat 7) and close the connection.
You might want to look at r1099556 which improves the handling of this case for Tomcat 7.
Thank-you. You saw that the exception is happening during req.updateCounters in process? http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/RequestInfo.java?annotate=581920 line 156: maxRequestUri=req.requestURI().toString(); called during I see I should have used 400 instead of 500. Is error not appropriate level to log at? They didn't close the connection in the two try/catch blocks a few lines before this line, but here it should?
No, you missed the key point in my review comment. Putting a try/catch around the point where the error is first seen is the wrong approach. The right approach is detecting when the packet length > buffer length and taking the appropriate action at that point (500 response, log message etc.)
(In reply to comment #4) > No, you missed the key point in my review comment. Putting a try/catch around > the point where the error is first seen is the wrong approach. The right > approach is detecting when the packet length > buffer length and taking the > appropriate action at that point (500 response, log message etc.) Thanks, but the try catch block is not around where the error is first seen. Depending how you count the patch is for the 3rd or 4th apache class up from where the exception occurs. Just below two other try catch blocks (all in the same method) of which this one is nearly identical to.
Again, the point where the exception occurs is not the place to handle this. The place to handle this is the point where Tomcat knows that the message is longer than than the buffer. Take a look at the AjpProcessor.readMeassge() method in Tomcat 7 and compare it to the same method in Tomcat 6. Any patch also needs to cover the AjpAprProcessor.
Is what you want from me, is to submit a patch copying Tomcat 7's AjpProcessor.readMessage to Tomcat 6? (In reply to comment #6) > Again, the point where the exception occurs is not the place to handle this. > The place to handle this is the point where Tomcat knows that the message is > longer than than the buffer. > > Take a look at the AjpProcessor.readMeassge() method in Tomcat 7 and compare it > to the same method in Tomcat 6. Any patch also needs to cover the > AjpAprProcessor.
6.0.x has reached end-of-life and this was already fixed in 7.0.x