You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2003/06/06 15:30:06 UTC
DO NOT REPLY [Bug 20546] New: - Tomcat sends an invalid HTTP response

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

Tomcat sends an invalid HTTP response

           Summary: Tomcat sends an invalid HTTP response
           Product: Tomcat 4
           Version: 4.0.3 Final
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Connector:Coyote HTTP/1.1
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: dcymbal@yahoo.com


I've uncovered a condition with 4.0.3 where the following response is returned 
to the client:

HTTP/1.1 400 Bad Request
Content-Type: text/html
Date: Wed, 28 May 2003 18:37:02 GMT
Connection: close
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)

Tomcat does not close the connection however which is causing the two
clients I've tested against (IE 6.0 and curl) to hang in their read loops.
I've been digging in RFC 2616 to try and understand who is at fault here,
and my understanding is that since there is no Content-Length returned and
the response is not chunked-encoded that the client should read until the
connection is closed.  Speaking with the curl developers they feel that this is 
a Tomcat bug and that the response needs to either set Content-Length: 0 or 
Tomcat needs to shutdown the connection after sending the header.  Also they 
point out that 2616 says that a 400 request SHOULD include an entity (but is 
obviously not required to do so).

So, any thoughts on this?  Are we understanding this properly as a server issue 
vs. a client problem?

P.S. The way I am able to duplicate this issue is to issue a GET request where 
the URI exceeds 32k.  I realize that in itself is pretty ridiculous and perhaps 
this behavior is some sort of defense against a DOS attack or the like but I 
could not find it documented anywhere.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org