You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Andreas Junghans <An...@fh-karlsruhe.de> on 2001/10/30 12:54:15 UTC
[Q+Patch] Error page behaviour in TC 3.x and 4.0.1
Hi there,
we're having the following problem: We have an error page in our web app to
display and log all errors, no matter where they occur. We started
develpment with Tomcat 3.2.1, and all went as expected. However, Tomcat
4.0.1 suppresses the error page when parts of the JSP have already been
flushed.
I've looked at the source and found that in
org/apache/catalina/valves/ErrorDispatcherValve.java the error page is
invoked using RequestDispatcher.forward(). This only works when no output
has been flushed up to the occurence of the exception. In Tomcat 3.2.1
(don't know about the other 3.x versions) however, the output of the error
page can appear in the middle of a half-flushed JSP.
I've consulted the spec about that, and it says (jsp-1_2-fcs-spec.pdf on
page 38):
"Any uncaught exceptions thrown in the body of the JSP page implementation
class result in the forwarding of the client request and uncaught exception
to the
errorPage URL specified by the JSP page (or the implementation default
behavior,
if none is specified)."
However, I don't think "forwarding" in this case is really meant literally
regarding the RequestDispatcher interface - if that was the case, there
should be some additional explanation what to do if forwarding fails. IMHO,
allowing the error page's output to appear after some flushed JSP output
makes more sense:
1. There is a visual indication of an exception that occured in the middle
of a JSP.
2. The error page can be used as a central place for error handling (for
example, we're logging to a database table there).
3. I can't think of any reasons that really make forward semantics
desirable.
Of course it would be nice to have the original page completely replaced by
the error page, but when some bits are already flushed, you cannot take them
back. So why not append the error page instead of just cutting off the rest
of the JSP? OK, there is a log entry about failed delivery of the error
page, but the user doesn't see that. A workaround is to increase the buffer
size so nothing get's flushed until the page is compete, but this is not
acceptable in many cases (e.g. when loading large tables constructed from a
database).
So what do you think? Any objections to changing RequestDispatcher.forward()
to RequestDispatcher.include() (see proposed patch attached to this
message)?
Best regards
---------------------------------------------------------------------------
Dipl.-Inform.(FH) Andreas Junghans
Steinbeis-Transferzentrum Industrielle Datenverarbeitung und Automation
Moltkestrasse 30 - 76133 Karlsruhe
Fon.: +49-721-925-1485 --- Fax: +49-721-925-1488
email: Andreas.Junghans@FH-Karlsruhe.de (privat: Bammus@aol.com)
---------------------------------------------------------------------------
Re: [Q+Patch] Error page behaviour in TC 3.x and 4.0.1
Posted by Remy Maucherat <rm...@home.com>.
> Your proposal seems to assume that the response to which the error message
> is "appended" is always HTML. This seems to me a very dubious assumption
> -- what happens if your servlet or JSP page is creating an XML document?
> Or outputting a binary image file? The conservative behavior is the
> current implementation, which replaces the old data if it can, but
> otherwise leaves it alone.
>
> Using an include() instead would have other negative consequences -- for
> example, you would not be able to set HTTP headers in the error page, due
> to the normal restrictions on includes. These are guaranteed to come as a
> nasty surprise to users who don't know what underlying mechanism is being
> used.
>
> Finally, it is very simple to avoid problems where the response has
> already been committed:
>
> * Make your response buffer big enough so that the commit
> has not happened yet, via response.setBufferSize().
>
> * Don't throw exceptions :-).
>
>
> Bottom line: I am -1 on this proposal.
Same. I was about to reply with about the same arguments (except, of course,
Craig formulated them better). The problem is that is will just make things
inconsistent. Errors can't be reliably reported when the response is already
committed. Of course, it may work just fine in a variety of specific cases
...
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Q+Patch] Error page behaviour in TC 3.x and 4.0.1
Posted by Andreas Junghans <An...@fh-karlsruhe.de>.
Hi there,
Craig wrote:
> Using an include() instead would have other negative consequences -- for
> example, you would not be able to set HTTP headers in the error page, due
> to the normal restrictions on includes. These are guaranteed to come as a
> nasty surprise to users who don't know what underlying mechanism is being
> used.
Agreed, I didn't see that. The other disadvantages you mentioned are
arguable, but this one convinced me. Thanks for this point.
Costin wrote:
> For JSPs - that's another issue, you could use taglibs ( but that has a
> performance impact ) or include the JSPs from a servlet ( another hit,
> probably smaller ).
I think including from a servlet is a good idea in our case. This should
also work reliably in arbitrary containers. Thanks for the suggestion.
Best regards
---------------------------------------------------------------------------
Dipl.-Inform.(FH) Andreas Junghans
Steinbeis-Transferzentrum Industrielle Datenverarbeitung und Automation
Moltkestrasse 30 - 76133 Karlsruhe
Fon.: +49-721-925-1485 --- Fax: +49-721-925-1488
email: Andreas.Junghans@FH-Karlsruhe.de (privat: Bammus@aol.com)
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Q+Patch] Error page behaviour in TC 3.x and 4.0.1
Posted by cm...@yahoo.com.
I do agree with Craig and with the conclusions.
I also agree with your expectation that error pages would get control when
an error occurs in your page. Unfortunately the spec uses the word
'forward' and at least 4.0 ( probably other containers ) use this.
Using big buffers is a workaround for small pages, but as a general rule
you shouldn't rely on error-page, but deal with the errors explicitely in
your code. This has other benefits as well - you'll have full control over
what happens, and the code to do that is relatively easy, at least for
servlets.
For JSPs - that's another issue, you could use taglibs ( but that has a
performance impact ) or include the JSPs from a servlet ( another hit,
probably smaller ).
Costin
On Tue, 30 Oct 2001, Craig R. McClanahan wrote:
> Your proposal seems to assume that the response to which the error message
> is "appended" is always HTML. This seems to me a very dubious assumption
> -- what happens if your servlet or JSP page is creating an XML document?
> Or outputting a binary image file? The conservative behavior is the
> current implementation, which replaces the old data if it can, but
> otherwise leaves it alone.
>
> Using an include() instead would have other negative consequences -- for
> example, you would not be able to set HTTP headers in the error page, due
> to the normal restrictions on includes. These are guaranteed to come as a
> nasty surprise to users who don't know what underlying mechanism is being
> used.
>
> Finally, it is very simple to avoid problems where the response has
> already been committed:
>
> * Make your response buffer big enough so that the commit
> has not happened yet, via response.setBufferSize().
>
> * Don't throw exceptions :-).
>
>
> Bottom line: I am -1 on this proposal.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Q+Patch] Error page behaviour in TC 3.x and 4.0.1
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Your proposal seems to assume that the response to which the error message
is "appended" is always HTML. This seems to me a very dubious assumption
-- what happens if your servlet or JSP page is creating an XML document?
Or outputting a binary image file? The conservative behavior is the
current implementation, which replaces the old data if it can, but
otherwise leaves it alone.
Using an include() instead would have other negative consequences -- for
example, you would not be able to set HTTP headers in the error page, due
to the normal restrictions on includes. These are guaranteed to come as a
nasty surprise to users who don't know what underlying mechanism is being
used.
Finally, it is very simple to avoid problems where the response has
already been committed:
* Make your response buffer big enough so that the commit
has not happened yet, via response.setBufferSize().
* Don't throw exceptions :-).
Bottom line: I am -1 on this proposal.
Craig
On Tue, 30 Oct 2001, Andreas Junghans wrote:
> Date: Tue, 30 Oct 2001 12:54:15 +0100
> From: Andreas Junghans <An...@fh-karlsruhe.de>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: tomcat-dev@jakarta.apache.org
> Subject: [Q+Patch] Error page behaviour in TC 3.x and 4.0.1
>
> Hi there,
>
> we're having the following problem: We have an error page in our web app to
> display and log all errors, no matter where they occur. We started
> develpment with Tomcat 3.2.1, and all went as expected. However, Tomcat
> 4.0.1 suppresses the error page when parts of the JSP have already been
> flushed.
>
> I've looked at the source and found that in
> org/apache/catalina/valves/ErrorDispatcherValve.java the error page is
> invoked using RequestDispatcher.forward(). This only works when no output
> has been flushed up to the occurence of the exception. In Tomcat 3.2.1
> (don't know about the other 3.x versions) however, the output of the error
> page can appear in the middle of a half-flushed JSP.
>
> I've consulted the spec about that, and it says (jsp-1_2-fcs-spec.pdf on
> page 38):
>
> "Any uncaught exceptions thrown in the body of the JSP page implementation
> class result in the forwarding of the client request and uncaught exception
> to the
> errorPage URL specified by the JSP page (or the implementation default
> behavior,
> if none is specified)."
>
> However, I don't think "forwarding" in this case is really meant literally
> regarding the RequestDispatcher interface - if that was the case, there
> should be some additional explanation what to do if forwarding fails. IMHO,
> allowing the error page's output to appear after some flushed JSP output
> makes more sense:
>
> 1. There is a visual indication of an exception that occured in the middle
> of a JSP.
> 2. The error page can be used as a central place for error handling (for
> example, we're logging to a database table there).
> 3. I can't think of any reasons that really make forward semantics
> desirable.
>
> Of course it would be nice to have the original page completely replaced by
> the error page, but when some bits are already flushed, you cannot take them
> back. So why not append the error page instead of just cutting off the rest
> of the JSP? OK, there is a log entry about failed delivery of the error
> page, but the user doesn't see that. A workaround is to increase the buffer
> size so nothing get's flushed until the page is compete, but this is not
> acceptable in many cases (e.g. when loading large tables constructed from a
> database).
>
> So what do you think? Any objections to changing RequestDispatcher.forward()
> to RequestDispatcher.include() (see proposed patch attached to this
> message)?
>
> Best regards
>
> ---------------------------------------------------------------------------
>
> Dipl.-Inform.(FH) Andreas Junghans
> Steinbeis-Transferzentrum Industrielle Datenverarbeitung und Automation
> Moltkestrasse 30 - 76133 Karlsruhe
> Fon.: +49-721-925-1485 --- Fax: +49-721-925-1488
> email: Andreas.Junghans@FH-Karlsruhe.de (privat: Bammus@aol.com)
> ---------------------------------------------------------------------------
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>