It is probably not a JBoss problem. JBoss actually doesn't participate in the actual communication. However, there are a few posts floating around (not in JBoss forums) about problems when the request has a malformed header - either the HTTP version was not set in the POST or the request did not send a content-length. Tomcat and WebLogic have reported problems in the past with these issues. You may want to check the Jetty forums or monitor your incoming request header with a HTTP trace tool.
Otherwise normally, the servlets and JSPs compute the content length based on the buffered output byte array to be placed on the output stream and properly configure the header portion. I think the gap in the spec concerning treatment for persistent HTTP sessions (dealing with HTTP 1.1 as well as supporting the older HTTP 1.0) has created this grief for the servlet engine implementors.
Hope that gets you a start.
Strange is, Jonlee, that both IIS and JRun4 sends automatically that content-length when i request a asp/aspx page or in the second case a JSP page before actually download its true content..!
I checked this with a ftp/http downloader called
'reget' and figured out that Content-Length should
be part of the HTTP header like the Date, Connection, Server, Content-Type and Cache-control..!
How can you say that?
Well, JBoss itself, AFAIK, plays no part in the web server/web client communication. You need to look to the servlet container.
Check the following newgroup threads as they indicate a few of the problems people have experienced with various servlet containers and content length in the header:
All I'm saying is that although content-length is a mandatory in HTTP 1.1, and in theory should be generated automatically, the servlet container may have a state in which it doesn't send the content-length in the header. And you will need to check with the specific servlet container developers to see if there are any known problems. Or debug the streams yourself and see what conditions are causing the issue you are experiencing and then check the container source code.
Just because you don't experience the problem in JRun or IIS doesn't mean other implementations will not have a problem.
And purely in the scientific pursuit of the nature of your issue, you might want to try with a different browser to see if the browser request header/request body is the initiating cause of the problem.