tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: 500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
Date Thu, 05 Apr 2012 16:07:14 GMT
-----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


Mime
View raw message