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=42409>. 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=42409 ------- Additional Comments From [EMAIL PROTECTED] 2007-05-31 05:15 ------- I too tested this scenario on Jetty, as well as on WebSphere Application Server (WAS) binaries and this problem doesn't occur with them. In both Jetty and WAS, I am able to see the extra response header even when using custom error page. My search of specification for anything against it has been in vain. Following is the piece of code that I have looked into: org.apache.catalina.core.StandardHostValve protected void status(Request request, Response response); protected boolean custom(Request request, Response response, ErrorPage errorPage); Here are my observations: 1) When a custom error page is used, client request is "forwarded" to the custom error page. Now, as per Servlet 2.4 specification (page 65, SRV.8.4): "The forward method of the RequestDispatcher interface may be called by the calling servlet only when no output has been committed to the client. If output data exists in the response buffer that has not been committed, the content must be cleared before the target servlets service method is called. If the response has been committed, an IllegalStateException must be thrown." I see that in current Tomcat code, in "protected boolean custom(Request request, Response response,ErrorPage errorPage)" method we are calling "response.reset(statusCode, message)" to clear the response content. This also clears the response headers that users might have set in their code. Question for Committers: I am seeing that the specification asks us to reset just the response buffer (before 'forwarding' requests) while we are resetting the entire response object (which also resets response headers). Can we replace the call to "response.reset(statusCode, message)" with a call to "response.resetBuffer()"? If yes, some of the "request.getAttribute(..)" calls in "protected boolean custom(Request request, Response response, ErrorPage errorPage)" method and hence some of the "request.setAttribute(..)" calls in "protected void status(Request request, Response response)" method might become redundant and could be removed as well. 2) When default error page is used, there is no request "forwarding" and hence no response resets (and hence the response headers that users set in their code are preserved). I think an error message is simply added to existing response's body and response is pushed to client. - Shiva -- 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]
