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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22141

response wrapper not being used in filtering an error-page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Component|Connector:Coyote HTTP/1.1   |Catalina
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-08-05 17:06 ---
Error page processing works like this:
- Request gets processed
- Then once the processing is done, the response is forwarded to the error page
(the JSP)

Your filter can't intercept forwards, so it is not invoked.
As for the ISE, I think it means just what it means (getOutputStream was already
used previously, so Jasper doesn't work; I assume that if you had your filter
invoked, it would work).
In Tomcat 5, you can map a filter to the request dispatcher forward and include,
which would allow you to make it work. I do think, however, that compression
belongs to the lower level (the HTTP connector).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] 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 [EMAIL PROTECTED]  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-03-21 01:38 ---
This has changed in the 2.4 spec, I suspect for this very reason. As Remy
indicated, one option is to use 5.0.x or 5.5.x 

I don't see an easy way for Tomcat 4.1.x to handle this. Both the filter that
calls getOutputStream() and the subsequent error page that calls getWriter()
(using a JSP will always result in a call to getWriter()) are both part of the
webapp. My instinct is, therefore, that the solution should also be part of the
webapp. That being said, if you would like to propose a patch for 4.1.x then
please do so - patches are always welcome.

One approach that is open to you is to use a servlet for your custom error page
and use getOutputStream().

I am setting the status on this back to INVALID on the basis that the spec, not
tomcat, is the underlying issue.

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