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=36763>. 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=36763 Summary: Setting content length to 0 in HttpServletResponse causes response to become falsely committed Product: Tomcat 5 Version: 5.0.28 Platform: Sun OS/Version: Solaris Status: NEW Severity: minor Priority: P4 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Overview Description: Should setting the content length of an HttpServletResponse to 0 cause that response to become committed? If yes, then this defect submission is unfounded. If no, then please consider the following two examples: Steps to Reproduce: Create two servlets as described below and examine what results when a GET request is made to each. Servlet 1: res.setStatus(302); res.setHeader("Location", "http://issues.apache.org";); res.setHeader("Content-length", "0"); (where res is the reference to the HttpServletResponse) Servlet 2: res.setHeader("Location", "http://issues.apache.org";); res.setHeader("Content-length", "0"); res.setStatus(302); Actual Results: When Servlet 1 is executed, I see: HTTP/1.x 302 Moved Temporarily Location: http://issues.apache.org Content-Length: 0 Date: SomeDate_GMT Server: Apache-Coyote/1.1 When Servlet 2 is executed, I see: HTTP/1.x 200 OK Location: http://issues.apache.org Content-Length: 0 Date: SomeDate_GMT Server: Apache-Coyote/1.1 (Servlet 1: 302, Servlet 2: 200) Expected Results: I expect both of these servlets to return what Servlet 1 responded with. For reference, the same behavior occurs if you use setContentLength(0). I believe the Servlet 2 invocation of setStatus doesn't have an effect because setting the content length to 0 caused the response to become incorrectly committed. Build Date & Platform: I'm running the official 5.0.28 release on Solaris 8. Additional Information: If this is in fact a defect, my only possible suggestion is that something may be wrong with the implementation of "isAppCommitted" in o.a.coy.t5.CoyoteResponse from jakarta-tomcat-catalina. In code above, I believe that invoking res.setStatus() results in isCommitted() being invoked on a CoyoteResponseFacade object. In turn, this invokes isAppCommitted on a CoyoteResponse object. For 5_0_28 the implementation of isAppCommitted reads: /** * Application commit flag accessor. */ public boolean isAppCommitted() { return (this.appCommitted || isCommitted() || isSuspended() || ((getContentLength() != -1) && (getContentCount() >= getContentLength()))); } It appears that this can evaluate to true even if everything is false up until the final piece: "|| ((getContentLength() != -1) && (getContentCount() >= getContentLength())));" And both getContentCount and getContentLength return 0. >From comments in the same file, getContentCount returns "the number of bytes actually written to the output stream." While getContentLength returns "the content length that was set or calculated for this Response." So, if I haven't written anything and I don't plan on writing any body part of the message, then both of these methods return 0, and we're committed even though neither the status line nor the headers have been necessarily written on the wire. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
