tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 22141] - response wrapper not being used in filtering an error-page
Date Tue, 15 Mar 2005 20:17:52 GMT
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=22141>.
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=22141


niels_meersschaert@businessweek.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         OS/Version|                            |All
           Platform|PC                          |All
         Resolution|INVALID                     |
            Version|4.1.27                      |4.1.29




------- Additional Comments From niels_meersschaert@businessweek.com  2005-03-15 21:17 -------
I am experiencing the exact same behavior in 4.1.29.  My compression filter modifies the response

object & calls getOutputStream in order to do that.  I can confirm that my filter is being
invoked, as I 
have logging throughout the doFilter method & can verify that the getOutputStream method
is called 
prior to going to an error-page.  Since I have the filter listening on /*, it gets invoked
 whether the 
resource exists or not.  If I have an error-page configured for 404 for example, the error-
page is throwing the IllegalStateException when I request a non-existant resource.

The only workaround I can find is to either not use the filter or not use the error-page handler.
 Neither 
is particularly useful.

I think the key issue here is that the filter we are using is processing not just the request,
but also the 
response object.  It appears that the request handling process order is filter before error-page
handler.  
Since a filter may alter both a request and a response object, by the time it reaches the
error-page 
handler, the response may have had getOutputStream called in order to do it's work.  The error-page

handler needs to support this situation, otherwise filters that modify responses can't be
used in 
conjuction with the error-page directive.

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


Mime
View raw message