DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30273>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30273 The HTTP 1.1 processor ignores "Connection: close" on response Summary: The HTTP 1.1 processor ignores "Connection: close" on response Product: Tomcat 4 Version: 4.1.30 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Connector:Coyote HTTP/1.1 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We have a number of servers that handle requests that, from the perspective of the client, only occur once in a great while. Because holding the connection open in such a situation only uses system resources unnecessarily; we have the servlet add a "Connection: close" header field to the response object. However, the Http11Processor class does not check for this header value in the response object and merrily assumes that the connection will stay open if the client says that it should. Thus, we have a situation where the client sees that the connection is supposed to go away (because it sees the "Connection: close" header), and the server thinks that the client is going to send another request (because it doesn't check). Now, some number of clients appear to close the connection immediately upon receipt of the response, while others wait for the server to perform the socket shutdown operation. The latter situation usually results in both client and server hanging until the server times the connection out. While we can work around this issue in many cases by setting the (undocumented!) "maxKeepAliveRequests" parameter on the connector to "1", this is somewhat unsatisfactory because then ALL requests for ALL servlets made through that connection are closed immediately. This makes it difficult to support situations where we have one servlet that needs to force close connections based either on information held in the response, or on specific APIs (URLs) being handled through that servlet; and another servlet (or URL/API) that can take full advantage of the streamlined communication that can take place when the connection is retained. While we could handle many such situations by configuring several connectors, one for short term and one for long term connectivity needs, and simply connecting to the short term or long term port as needed, we only have API level policy on connection term lengths rather than full program control over when the connection actually should be dropped. While this behavior is not spelled out in the Java Servlet Specification (v2.3) it IS spelled out in RFC 2068 (section 14.10) - the HTTP v1.1 definition. Correct behavior is to close the socket after the response is sent if "Connection: close" is sent to the client. Whether this header is sent by the Http11Processor or by the servlet the processor must respect this functionality. As an aside on implementation: the Http11Processor should NOT add a second "Connection: Keep-Alive" or "Connection: close" field to the header if a "Connection" header field has already been set. However, a "Connection: Keep-Alive" may reasonably be replaced with a "Connection: close" if necessary, but a "Connection: close" should never be replaced with a "Connection: Keep-Alive". --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
