DO NOT REPLY [Bug 35905] New: - Response Already Committed Apache\Tomcat mod_jk connector

[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=35905>.
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=35905

           Summary: Response Already Committed Apache\Tomcat mod_jk
                    connector
           Product: Cocoon 2
           Version: 2.1.7
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: major
          Priority: P2
         Component: core
        AssignedTo: dev@cocoon.apache.org
        ReportedBy: dbennett1556@netscape.net


We run a number of application servers with Tomcat instances running other
applications ( not using Cocoon ) fronted by Apache\mod_jk instances 
and have not encountered this problem before. 

Scenario:

Using Apache web server - mod_jk connector fronting a Tomcat server running Cocoon.

A request for a server response that has previously been cached by the browser
and the request contains an "If-Modified-Since" header. The response in Cocoon
has not been modified.

A pipeline match with a generator, this scenario does not happen with a reader.

Cocoon: 

The response to the request is checked to see if it has been modified.

If the Response Is Not Modified a response status is set to
HttpServletResponse.SC_NOT_MODIFIED in the
HTTPEnvironment.setResponseIsNotModified()

The following code in the CocoonServlet tries to flush and close the
outputstream at the end of the service method which causes the connector to log
a "Response Already Committed". 

This in turn causes the environment ( Browser <-> Apache <-> Tomcat <-> Cocoon )
not to function properly there after.

The side effects of this cause a unusable environment where further calls to
Cocoon do not function even when the resource on the server is modified. 

Comment:

If the HttpServletResponse.SC_NOT_MODIFIED status is set there should be nothing
in the outputstream so flush() and close() are maybe not expected by the mod_jk
connector. Calls to out.flush() and out.close() are unnecessary regardless. 

Possible Solution:

Add method public boolean boolean isResponseModified() to the Environment
Interface. In implementations set boolean value when setResponseIsNotModified()
is called.

Add conditional check in the CocoonServlet to see if the response has been
modified in the Environment 
before the out.flush() and out.close()  are called. 

if(env.isResponseModified()){ 
    try {	            	   	    
	 OutputStream out = res.getOutputStream();
	 out.flush();
	 out.close();
    ...
}

We made this change and it solved the problem, we can submit changes if this is
the correct solution.


Scenario Environment:


FireFox Browser 1.0.6 
Apache 2.0.54
JDK1.5
mod_jk 1.2.14
JBoss 4.0.2\Tomcat 5.5.9 or Tomcat 5.5.9 without JBoss
Cocoon 2.1.7

-- 
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.