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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
