tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From manuel aldana <>
Subject Re: 500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
Date Thu, 05 Apr 2012 18:47:05 GMT
Am 05.04.12 18:07, schrieb Christopher Schultz:
> Hash: SHA1
> Manuel,
> On 4/5/12 11:42 AM, manuel aldana wrote:
>> Inside web.xml I defined<error-page>500..., so 500-status is
>> resolving to JSP error pages. I get inconsistent behaviour when an
>> Exception occurs during JSP rendering.
>> 1) JSP syntax error (e.g. broken XML): === ->  500 status is set
>> correctly ->  forward to jsp-error page is done correctly and 500
>> returned to browser
>> 2) JSP runtime error: === ... ${model.causingNullPointerException}
>> ... ->  200 status ->  i.e. broken 500-forward to error.jsp ->  I get
>> broken HTML inside browser
> How much broken HTML do you get?
> It's possible that the response has already been committed to the
> client and there's no way to show the error page instead.
> Check your log files for "Response already committed" or related errors.
>> - In 2nd case "some" of jsp is rendered and written to
>> output-buffer and resetting-status is prohibited (see isCommitted()
>> check) =>  i.e. there is no way forwarding to 500 status when error
>> occurred during runtime of JSP rendering
> Correct.
>> I guess this is a bug (want to backup first before creating
>> trace-ticket)?
> If this is a bug, it's in your webapp: you generate too much content
> before you have any errors.

Inside JSP we have a backing model, which contains the dynamic data to 
be displayed inside JSP. Itself the model is held quite simple, but due 
to programming errors it can happen, that null-references occur. This is 
very rare, but we need to be notified somehow (due to explicit ERROR 
logging). The log to catalina.log isn't sufficient for our log setup (we 
use graylog2-server).

With bug@tomcat I meant that it error.jsp forwarding is not consistent 
between an exception at the "very start" of JSP rendering (e.g. syntax 
error) vs. error later during rendering. But I agree there is no way to 
"revert" status codes and content once bytes are sent to http-consumer.

>> Do you know a workaround for this?
> Several options (I'm sure there are more):
> 1. Don't throw exceptions ;)
> 2. Increase your output buffer (negative performance considerations)
> 3. Buffer the *entire* response (negative performance considerations,
>     requires additional code)
> Honestly, #1 is the best policy IMO, since you really should have all
> of your dangerous activities out of the way before you start
> generating a response.
1) see above. exception was NullPointerException, which was a plain bug 
in our code.
2 + 3) not an option for us as we have high traffic volume, the problem 
of exception is much more seldom, so that we don't want to sacrifice a 
fix here.

>> Currently I have workaround to have a special Filter checking for
>> Exceptions and including 200 status. The bad thing is that still
>> browser/users get returned 200 OK status, though error occurred ,
>> because resetting status isn't allowed.
> I don't know how you will correct malformed HTML in that case.
The malformed HTML wasn't an issue. Bad thing was that 1) we missed it 
in our log-infrastructure and 2) didn't see it on apache logs (because 
status was 200 OK), we monitor on 500 status codes.

What I will do create an interceptor which checks for the combination of 
200 status-code and exception. Alternatively I will see how to include 
tomcat logging plug to our used This is cleaner but 
also higher effort, as I need to plugin logging-handling to tomcat.

Thanks for answer and happy easter.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message