tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Bergsten <h...@gefionsoftware.com>
Subject Re: Outstanding bugs before 3.2 final?
Date Thu, 21 Sep 2000 19:35:22 GMT
Larry Isaacs wrote:
> 
> I'll admit I may have overstepped a bit, going for a quick fix
> giving security the priority over ease of development.  I
> didn't think I had time work out a configuration parameter
> for server.xml.
> 
> IMHO, being able to easily guarantee that stack traces can't
> occur is serious enough that it should be addressed in
> Tomcat 3.2.  With stack traces in the default handler,
> it would be difficult to insure that the default handler
> couldn't accidentally be invoked under the right conditions.
> 
> To view stack traces the intent was to add DisplayException.jsp
> as an error-page for java.lang.Throwable in the web.xml.
> However, I agree this fails the ON BY DEFAULT requirement
> miserably.
> [...]

How about the reversed model; roll back the stack traces and
add an example of a custom error page that does not show the
stack trace, that can be mapped to java.lang.Throwable in the web.xml
file for an app?

I agree with Alex that default should be to show the stack trace.
Hopefully, stack traces are most common during development and
that's when it's useful to get them displayed. In a production
environment, I think it's fair to ask that deployers make a few
adjustments such as adding another error page. Correct me if I'm
wrong, but I believe this is similar to other useful development
features such as auto-reload; it's on by default but should be
disabled for deployment.

> So, I willing to go with the majority.  I can roll the stack
> traces back into the default handling, or continue modifications
> to add a configuration parameter to server.xml.  What is the
> feeling on this?

My vote is for rolling back the change and leave it at that for 3.2.
We must get 3.2 out; it's been far too long already. A note can
be added in the README about the possibility to define a more
secure error page for an application.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com

Mime
View raw message