tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 49718] New: Fix for bug 46984 breaks HTTP 0.9 requests
Date Fri, 06 Aug 2010 18:59:05 GMT

           Summary: Fix for bug 46984 breaks HTTP 0.9 requests
           Product: Tomcat 5
           Version: 5.5.29
          Platform: Sun
        OS/Version: Solaris
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Connector:HTTP

   * issue found in 5.5.29 and still exists in 5.5.30.
   * support for HTTP simple requests is broken as of tomcat 5.5.28.
   * root cause: fix added to incorrect block in request line parser.


We've recently upgraded our product to use Apache Tomcat 5.5.29 from Apache
Tomcat 5.5.25.  While testing, it was determined that some of our older clients
who sent the following HTTP 0.9 request, described as "Simple Requests" in RFC

GET /login/servlet/myservlet?ReplyType=ACTION&User=blah&Password=blahblah

Would receive the following response:

HTTP/1.1 400 Bad Request
Server: Apache-Coyote/1.1
Transfer-Encoding: chunked
Date: Thu, 29 Jul 2010 19:26:06 GMT
Connection: close

For the same request using Tomcat 5.5.25, we'd get the correct
"Simple-Response" as required by RFC 1945.

After turning debugging on, I determined that tomcat was throwing the following

2010-07-29 15:49:22,068 [http-8080-Processor24] DEBUG
org.apache.coyote.http11.Http11Processor - Error parsing HTTP request header
java.lang.IllegalArgumentException: Invalid character (CR or LF) found in
method name
 at org.apache.coyote.http11.Http11Processor.process(

Which doesn't make any sense.

After some testing, I found that if an extra space character was added after
the URI, I would once again get the correct "Simple-Response" back from tomcat.

Based on the error message, I assumed it was likely the following bug fix in
tomcat 5.5.28 that likely introduced the issue:

46984: Reject requests with invalid HTTP methods with a 400 rather than a 501.

Looking through the source, I found that this is the code block that is
throwing the exception:

$ diff
>             // Spec says no CR or LF in method name
>             if (buf[pos] == Constants.CR || buf[pos] == Constants.LF) {
>                 throw new IllegalArgumentException(
>                         sm.getString("iib.invalidmethod"));
>             }
<                 throw new IOException
>                 throw new IllegalArgumentException

And digging through the code repository, this is the subversion revision in
which this issue was introduced:

svn diff -c 781763

Although I've only briefly perused this code, it seems that the likely error is
that this code block was added to the "Reading the URI" code block as opposed
to the "Reading the method name" code block, as intended.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message