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=7852>. 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=7852 Closing connections on error causes problems Summary: Closing connections on error causes problems Product: Tomcat 4 Version: 4.0.3 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Connector:HTTP/1.1 (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm not sure why the code works this way, but I believe it's wrong. On line 279 of org.apache.catalina.connector.http.HttpResponseImpl.java, the following code is found: if (getStatus() < HttpServletResponse.SC_BAD_REQUEST) { if ((!isStreamInitialized()) && (getContentLength() == -1) && (getStatus() >= 200) && (getStatus() != SC_NOT_MODIFIED) && (getStatus() != SC_NO_CONTENT)) setContentLength(0); } else { setHeader("Connection", "close"); } This means that any time there's a 4xx or 5xx, the connection is closed. This seems to be strange behavior, since the HTTP/1.1 spec states: "Persistent HTTP connections have a number of advantages: ... errors can be reported without the penalty of closing the TCP connection." Tomcat's behavior isn't technically illegal, but it's a violation of the intent of the specification. My small company has an application that occasionally needs to act as a communications proxy. We've found that the code above makes it impossible to complete an NT authentication because Tomcat closes the connection for a 401. I'm sure some will be happy enough to mumble about Microsoft. :( Anyway, we've had enough luck changing SC_BAD_REQUEST to SC_INTERNAL_SERVER_ERROR. I suspect that the best behavior would be to remove the if and the else clause altogether. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
