DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5861>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5861 java.lang.NumberFormatException when using non-standard HTTP headers with length of 8 characters and non numeric value Summary: java.lang.NumberFormatException when using non-standard HTTP headers with length of 8 characters and non numeric value Product: Tomcat 4 Version: 4.0.1 Final Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: AJP Connector AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi, using Tomcat 4.0.1 in conjunction with mod_jk and Ajp13 connections I got the following problem: One of my clients sends the following http request to my Apache server (just changed server name) GET http://someserver.com/somewhere/somefile.html HTTP/1.1 Accept: */* UA-OS: Windows CE (POCKET PC) - Version 3.0 UA-color: color16 Host: someserver.com User-Agent: Mozilla/2.0 (compatible; MSIE 3.02; Windows CE; PPC; 240x320) Proxy-Connection: Keep-Alive This request will be forwarded via mod_jk and an Ajp13 connection to my tomcat instance. Executing this request will result in a "hanging" connection (no response, but connection won't be closed). If you remove "UA-color: color16" from the request above, everything works fine. I took a look at catalina.out and detected that everytime I execute the query above the following exeception is thrown: java.lang.NumberFormatException at org.apache.tomcat.util.buf.Ascii.parseInt(Ascii.java:188) at org.apache.tomcat.util.buf.ByteChunk.getInt(ByteChunk.java:439) at org.apache.tomcat.util.buf.MessageBytes.getInt(MessageBytes.java:565) at org.apache.ajp.Ajp13.decodeRequest(Ajp13.java:393) at org.apache.ajp.Ajp13.receiveNextRequest(Ajp13.java:309) at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:339) at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:424) at java.lang.Thread.run(Thread.java:484) I took a look at line 393 from Ajp13.java (from the jakarta-tomcat-connectors) and detected the following: Because UA-color has 8 characters hId is set to 8 which is equal to SC_REQ_CONTENT_LENGTH. Therefore the if condition in line 392 is true and the content length is expected as header value. Therefore everything works fine if I use UA-colors (9 Characters) or an integer value for UA-color in my request. Lines 369-401 from Ajp13.java // Header names are encoded as either an integer code starting // with 0xA0, or as a normal string (in which case the first // two bytes are the length). int isc = msg.peekInt(); int hId = isc & 0xFF; MessageBytes vMB=null; isc &= 0xFF00; if(0xA000 == isc) { msg.getInt(); // To advance the read position hName = headerTransArray[hId - 1]; vMB= headers.addValue(hName); } else { // XXX Not very elegant vMB = msg.addHeader(headers); if (vMB == null) { return 500; // wrong packet } } msg.getMessageBytes(vMB); // set content length, if this is it... if (hId == SC_REQ_CONTENT_LENGTH) { int contentLength = (vMB == null) ? -1 : vMB.getInt(); // 393 req.setContentLength(contentLength); } else if (hId == SC_REQ_CONTENT_TYPE) { ByteChunk bchunk = vMB.getByteChunk(); req.contentType().setBytes(bchunk.getBytes(), bchunk.getOffset(), bchunk.getLength()); } } >From my point of view the mistake seems to be to check the if condition in line 392 even if isc & 0xFF00 isn't 0xA000 (Which is not the case, as I saw in a snoop). Because of this I would propose the following patch to solve the problem: --- jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java.orig Wed Oct 10 08:35:22 2001 +++ jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java Tue Jan 15 10:34:37 +2002 @@ -378,26 +378,30 @@ msg.getInt(); // To advance the read position hName = headerTransArray[hId - 1]; vMB= headers.addValue(hName); + + msg.getMessageBytes(vMB); + + // set content length, if this is it... + if (hId == SC_REQ_CONTENT_LENGTH) { + int contentLength = (vMB == null) ? -1 : vMB.getInt(); + req.setContentLength(contentLength); + } else if (hId == SC_REQ_CONTENT_TYPE) { + ByteChunk bchunk = vMB.getByteChunk(); + req.contentType().setBytes(bchunk.getBytes(), + bchunk.getOffset(), + bchunk.getLength()); + } + } else { // XXX Not very elegant vMB = msg.addHeader(headers); if (vMB == null) { return 500; // wrong packet } - } - - msg.getMessageBytes(vMB); - // set content length, if this is it... - if (hId == SC_REQ_CONTENT_LENGTH) { - int contentLength = (vMB == null) ? -1 : vMB.getInt(); - req.setContentLength(contentLength); - } else if (hId == SC_REQ_CONTENT_TYPE) { - ByteChunk bchunk = vMB.getByteChunk(); - req.contentType().setBytes(bchunk.getBytes(), - bchunk.getOffset(), - bchunk.getLength()); + msg.getMessageBytes(vMB); } + } byte attributeCode; Is this ok? Any comments? Best regards R�diger Pl�m -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
