DO NOT REPLY [Bug 9498] New: - org.apache.ajp.RequestHandler#doRead(Ajp13) does not always properly return an integer of 0x00 - 0xFF

[bu...@apache.org]

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=9498>.
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=9498

org.apache.ajp.RequestHandler#doRead(Ajp13) does not always properly return an integer of 0x00 - 0xFF

           Summary: org.apache.ajp.RequestHandler#doRead(Ajp13) does not
                    always properly return an integer of 0x00 - 0xFF
           Product: Tomcat 4
           Version: Unknown
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Connector:JK/AJP (deprecated)
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: stoehr_sukachevin@hotmail.com


Not sure if org.apache.ajp.RequestHandler is being updated any more or not 
since the JK/AJP connector is deprecated, but just in case....

org.apache.ajp.RequestHandler#doRead(Ajp13) does not always properly return an 
integer of 0x00 - 0xFF since a byte is converted to an integer simply by 
casting it to a char.

So instead of:

        return (char) ch.bodyBuff[ch.pos++];

do:

        return ch.bodyBuff[ch.pos++] & 0xFF;


This same type of issue came up in 
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3534.

For example, if the Content-Encoding of an HTTP request is gzip, then gzip's 
magic number in the first two bytes of the header will be read in by a servlet 
improperly (0x001F and 0xFF8B instead of 0x001F and 0x008B).

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>