You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@tomcat.apache.org by bu...@apache.org on 2005/03/15 21:17:52 UTC

DO NOT REPLY [Bug 22141] - response wrapper not being used in filtering an error-page

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:

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