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 5861] New: - java.lang.NumberFormatException when using non-standard HTTP headers with length of 8 characters and non numeric value
Date Tue, 15 Jan 2002 14:28:28 GMT
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: tomcat-dev@jakarta.apache.org
        ReportedBy: ruediger.pluem@vodafone-telecommerce.de


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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message