You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pid <pi...@pidster.com> on 2010/08/12 23:02:19 UTC
Re: Need confirmation of issue: HTTP simple requests broken as of
Apache Tomcat 5.5.28.
On 11/08/2010 14:38, Nick Langlois wrote:
> Hi,
> I need confirmation of an issue I've encountered while upgrading from
> Apache Tomcat 5.5.25 to 5.5.29 running in Java 1.5.0_22 on Solaris 10u8.
> Unfortunately, I'm going about this backwards as I've already created a bug
> report. The tomcat site, however, recommends that confirmation should be
> received as to whether a suspected bug is a bug or not on the tomcat user
> mailing list.
>
> Issue found in: Apache Tomcat 5.5.29
> Issue introduced in: Apache Tomcat 5.5.28
>
>
> Issue:
>
> Get "HTTP/1.1 400 Bad Request" response back when Tomcat receives an HTTP
> simple request (no HTTP version specified in request line).
>
>
> Expected behaviour:
>
> According to its documentation, tomcat 5.5.x's HTTP connector is compliant
> with the HTTP/1.1 RFC, and will seamlessly transition to HTTP/1.0 if an
> HTTP/1.0 request is received. For backwards compatibility (I assume), the
> HTTP 1.0 RFC handles HTTP 0.9 requests for older clients, referring to these
> requests as "simple requests" in the RFC. Thus, according to the RFC,
> tomcat should respond with a "simple response" should it receive a "simple
> request".
>
>
> Example of expected behaviour:
>
> wcars1u7-unit1# telnet localhost 5555
> Trying 127.0.0.1...
> Connected to localhost.
> Escape charac= ter is '^]'.
> GET /index.html
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
> <html>
> <head>
> <title>Zack Networks Application Server</title>
> <style type="text/css">
> BODY {margin: 64px;
> background: #ffffff;
> cursor: default;}
> H1, H2, H3, H4, H5, H6
> {font-family: Zack-Networks-Primary, Arial-Bold, Arial,
> Helvetica, Sans-Serif;
> color: #003399;}
> </style>
> </head>
>
> <body>
> <h2>No application is available at this URL. Please see the product
> documentation for the correct URL.</h2>
> </body>
> </html>
> Connection to localhost closed by foreign host.
> wcars1u7-unit1#
>
>
> Behaviour I'm seeing:
>
> wcars1u7-unit1# telnet localhost 8080
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> GET /index.html
> HTTP/1.1 400 Bad Request
> Server: Apache-Coyote/1.1
> Transfer-Encoding: chunked
> Date: Tue, 10 Aug 2010 18:32:36 GMT
> Connection: close
>
> 0
>
> Connection to localhost closed by foreign host.
> wcars1u7-unit1#
>
>
> With debug enabled, tomcat logs the following thrown exception:
>
> 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.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:474)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
>
> at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
> at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
>
> at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
> at java.lang.Thread.run(Thread.java:595)
>
> Further information can be found in the bug report:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=3D49718
>
> Can someone please confirm this issue?
> Is it possible to get some indication as to if, when, and in what version
> this issue will be fixed in the Tomcat 5.5.x release?
I'm guessing that no-ones replying, because there's no known issue here.
Are you sure the issue isn't a result of the means of making the test
request?
p
Re: Need confirmation of issue: HTTP simple requests broken as of
Apache Tomcat 5.5.28.
Posted by Nick Langlois <he...@gmail.com>.
On Thu, Aug 12, 2010 at 5:02 PM, Pid <pi...@pidster.com> wrote:
> On 11/08/2010 14:38, Nick Langlois wrote:
> > Hi,
> > I need confirmation of an issue I've encountered while upgrading from
> > Apache Tomcat 5.5.25 to 5.5.29 running in Java 1.5.0_22 on Solaris 10u8.
> > Unfortunately, I'm going about this backwards as I've already created a
> bug
> > report. The tomcat site, however, recommends that confirmation should be
> > received as to whether a suspected bug is a bug or not on the tomcat user
> > mailing list.
> >
> > Issue found in: Apache Tomcat 5.5.29
> > Issue introduced in: Apache Tomcat 5.5.28
> >
> >
> > Issue:
> >
> > Get "HTTP/1.1 400 Bad Request" response back when Tomcat receives an HTTP
> > simple request (no HTTP version specified in request line).
> >
> >
> > Expected behaviour:
> >
> > According to its documentation, tomcat 5.5.x's HTTP connector is
> compliant
> > with the HTTP/1.1 RFC, and will seamlessly transition to HTTP/1.0 if an
> > HTTP/1.0 request is received. For backwards compatibility (I assume),
> the
> > HTTP 1.0 RFC handles HTTP 0.9 requests for older clients, referring to
> these
> > requests as "simple requests" in the RFC. Thus, according to the RFC,
> > tomcat should respond with a "simple response" should it receive a
> "simple
> > request".
> >
> >
> > Example of expected behaviour:
> >
> > wcars1u7-unit1# telnet localhost 5555
> > Trying 127.0.0.1...
> > Connected to localhost.
> > Escape charac= ter is '^]'.
> > GET /index.html
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
> > <html>
> > <head>
> > <title>Zack Networks Application Server</title>
> > <style type="text/css">
> > BODY {margin: 64px;
> > background: #ffffff;
> > cursor: default;}
> > H1, H2, H3, H4, H5, H6
> > {font-family: Zack-Networks-Primary, Arial-Bold, Arial,
> > Helvetica, Sans-Serif;
> > color: #003399;}
> > </style>
> > </head>
> >
> > <body>
> > <h2>No application is available at this URL. Please see the product
> > documentation for the correct URL.</h2>
> > </body>
> > </html>
> > Connection to localhost closed by foreign host.
> > wcars1u7-unit1#
> >
> >
> > Behaviour I'm seeing:
> >
> > wcars1u7-unit1# telnet localhost 8080
> > Trying 127.0.0.1...
> > Connected to localhost.
> > Escape character is '^]'.
> > GET /index.html
> > HTTP/1.1 400 Bad Request
> > Server: Apache-Coyote/1.1
> > Transfer-Encoding: chunked
> > Date: Tue, 10 Aug 2010 18:32:36 GMT
> > Connection: close
> >
> > 0
> >
> > Connection to localhost closed by foreign host.
> > wcars1u7-unit1#
> >
> >
> > With debug enabled, tomcat logs the following thrown exception:
> >
> > 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.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:474)
> > at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> >
> > at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
> > at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
> > at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
> >
> > at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
> > at java.lang.Thread.run(Thread.java:595)
> >
> > Further information can be found in the bug report:
> >
> > https://issues.apache.org/bugzilla/show_bug.cgi?id=3D49718
> >
> > Can someone please confirm this issue?
> > Is it possible to get some indication as to if, when, and in what version
> > this issue will be fixed in the Tomcat 5.5.x release?
>
> I'm guessing that no-ones replying, because there's no known issue here.
>
> Are you sure the issue isn't a result of the means of making the test
> request?
>
I'm sure, as I've been doing it for years. It's great for debugging in
environment where you may not have any access to a system other than through
an established ssh or telnet session to the server
for security reasons (like at many of our customers).
You can do something similar to debug HTTPS requests using the "openssl
s_client" option.
In either case, you just must ensure you send your HTTP request before the
server side times out and
closes the TCP connection.
>
> p
>
>