DO NOT REPLY [Bug 36763] New: - Setting content length to 0 in HttpServletResponse causes response to become falsely committed

[bu...@apache.org]

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: northridge@gmail.com


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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org