As the Tomcat user mailing list has not been much help in solving two annoying Tomcat issues, I hereby invoke the Lazy Web!

The first issue involves Tomcat blocking on a call to HttpServletRequest.getSession(). This seems to only occur when I am debugging Tomcat remotely from within IDEA under Windows XP. I am using the latest version of Tomcat, JVM 1.4.1-b21 and IDEA 3.0.1. This is possibly an IDEA issue. Since the problem only seems to occur when debugging, it is not one needing an urgent solution.

The second and more annoying issue involves a mangled Content-Length header in the occasional HTTP response. When I say “mangled”, I mean that the header field does not read as “Content-Length”, but something almost like “Content-Length”. Naturally, a response without a Content-Length field violates the HTTP specifications. The content and all other header fields are never mangled—only Content-Length, only sometimes, and usually when the length of the body is non-zero.

The following code snippet illustrates how I am setting the response:

private void writeHttpContent( HttpServletResponse response, byte[] contentsOutBytes ) throws Exception
{
    response.setContentType( "application/octet-stream" );
    response.setContentLength( contentsOutBytes.length );

    // Only bother writing if there is something to write.
    if( contentsOutBytes.length > 0 )
    {
        // Grab an output stream from the HTTP response and write to it
        BufferedOutputStream out = new BufferedOutputStream( response.getOutputStream() );
        out.write( contentsOutBytes );
        response.getOutputStream().flush();
    }
}

I have tried a few variations on the above including calling flush() on the BufferedOutputStream, and closing either response.getOutputStream() or BufferedOutputStream, but with the same result. Using response.setHeader( "Content-Length", Integer.toString( contentsOutBytes.length ) ) makes no difference, as one would hope. I also eliminated the call to response.setContentLength() but that always resulted in a missing Content-Length.

Here is an example of a mangled response:

Content-Type: application/octet-stream
Content-Lengtd><b 
Date: Tue, 25 Feb 2003 17:28:49 GMT
Server: Apache Coyote/1.0

To date, I have only seen this happen on our Debian Linux box running Tomcat 4.1.16-1 from testing and Sun’s J2SDK1.4.1_01-b01. This led me to believe that it could be a problem with Debian, but a post to the debian-java mailing list turned up nothing.

Naturally, the above problem cannot be reproduced but it does happen often enough to be terribly annoying for our client devices. Furthermore, I have a few Java apps hitting the servlet on a consistent basis using HTTP/1.0 and they never experience this problem. I can’t understand how this could be limited to HTTP/1.1.

If you have any suggestions—any suggestions at all—then do not hesitate to leave a comment. At this point, I’d accept chicken bone voodoo magic as a possible solution.

Update (05/15): After spending most of today and some of yesterday investigating this issue, we have determined that it was the router causing the munged bytes, always in the same offset within a packet. The router in question is a LinkSys, and will be subsequently hurled, beaten and torched sometime in the very near future.