tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <tere...@tmbsw.com>
Subject Re: 500 HTTP-status forwarding broken (JSP rendering + Exception occurence)
Date Thu, 05 Apr 2012 22:04:16 GMT
  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


Mime
View raw message