You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by manuel aldana <al...@gmx.de> on 2012/04/05 17:42:47 UTC
500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
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
Second case is quite dangerous because we didn't see anything inside
logs and 200 status was presented though we had production bug. Just
accidently looking at catalina.log (stdout logging of all exception)
covered this.
I checked source-code (6.0.35):
===
core.StandardHostValue:282:
...
response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
connector.Response:1457
...
if (isCommitted())
return;
...
My assumption:
- In 1st case 500 forward + status setting works fine, because JSP
rendering breaks from beginning and no content is flushed to output-buffer
- 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
I guess this is a bug (want to backup first before creating trace-ticket)?
Do you know a workaround for this? 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.
Thanks for support.
--
manuel aldana
mail: maldana.geek@gmail.com | manuel@aldana-online.de
blog: www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception
occurence)
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
On 1:59 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
>
>> 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.
>
++. All processing that is likely to generate an exception should be
completed before any output is generated.
-Terence Bandoian
>> 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.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk99wzIACgkQ9CaO5/Lv0PArgQCgxCY0TAXJffHwEbfqFYSquGnZ
> q7oAni/aTXMjNnC/qbLxeQBixC1DbHW0
> =S5iP
> -----END PGP SIGNATURE-----
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception
occurence)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Manuel,
On 4/5/12 2:47 PM, manuel aldana wrote:
> 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.
Right.... this can't possibly be attributed to a bug in Tomcat.
Instead, one might say that this is simply a fact of life for
streaming data applications. Your only recourse is bigger buffers.
> What I will do create an interceptor which checks for the
> combination of 200 status-code and exception.
I'm not sure how you would scan for that, other than a filter that
simply records all exceptions that are thrown (which is easy to do).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk999/8ACgkQ9CaO5/Lv0PAc6ACgsUM0qx5VN6+6496za7tUWrtr
HggAn3pd1bX/Z8xlOrfBCGUummqvHQQw
=ZGL3
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception
occurence)
Posted by manuel aldana <al...@gmx.de>.
Am 05.04.12 18:07, schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
https://github.com/Graylog2/graylog2-server/wiki. 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: 500 HTTP-status forwarding broken (JSP rendering + Exception
occurence)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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.
> 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.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk99wzIACgkQ9CaO5/Lv0PArgQCgxCY0TAXJffHwEbfqFYSquGnZ
q7oAni/aTXMjNnC/qbLxeQBixC1DbHW0
=S5iP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org