• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Catching Error Code in Tomcat

 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't want tomcat to come up with its standard error page when a non-200 status code is returned. Is this done by using the <error-code> tag in web.xml?

If this is the solution, is there a way to specify an error page base on a range of status codes? It is difficult to foresee all the possible error status code that might be returned by tomcat and I can't list all of them in my web.xml.
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64617
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not Tomcat-specific, so moving to the Servlets forum.
 
Bruno Boehr
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> Is this done by using the <error-code> tag in web.xml?

Correct.

> is there a way to specify an error page base on a range of status codes?

As of the current Servlet Spec version, 2.5, the answer is no.

> It is difficult to foresee all the possible error status code that might be returned by tomcat

If you are talking about some sort of a "default" error page, then I think you can make use of the following statement that appears in section 9.9.2 of the spec, Error Pages:

"If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500."

To me, this sounds like if you make sure you have an error page defined for status code 500, it will work as a safety net capturing everything that misses all other error page definitions.

In addition to this, you might want to leverage the other error page resolution mechanism which is based on exception type:

<error-page>
<exception-type>your.fully.qualified.ExceptionType</exception-type>
<location>/your-custom-error-page.html</location>
</error-page>

But this really calls for a framework, or at least an exception class hierarchy if you want to make effective use of it, and you might be better off handling errors in a way that is more consistent with your application's organization/workflow, without relying on the servlet-providing mechanism.
 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

"If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500."

To me, this sounds like if you make sure you have an error page defined for status code 500, it will work as a safety net capturing everything that misses all other error page definitions.

No, this doesn't catch everything. There are some error pages that are generated by tomcat, 2 examples are:

HTTP Status 408 - The time allowed for the login process has been exceeded. If you wish to continue you must either click back twice and re-click the link you requested or close and re-open your browser

HTTP Status 400 - Invalid direct reference to form login page

The first one happens if you wait too long in your login form. The second one happens if you
directly access the login page. Both errors are [B]generated by tomcat[/B}, not by servlet. I can
define error pages for this 2 error codes, but what if there are some other error codes that
tomcat may generate. I can't foresee all of them.
 
Bruno Boehr
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> No, this doesn't catch everything. There are some error pages that are generated by tomcat

Despite your having a 500 error page specified in web.xml? Well, too bad they do not abide by the spec.

Whatever the case, there is still no syntax to define an error page per a range of status code values. I wish we lived in an ideal world...
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I can't foresee all of them

You don't have to. I think that most web app only consider the more frequent error codes. You don't have to support the "Gone to the toilet without paper" error is you don't need to

You can still check them all, there aren't so many. A little copy paste is needed :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Perhaps, I use an example to illustrate:

1. Define a login page as in web.xml by:


2. Access the /login.jsp directly from a browser and enter a valid username/password.

3. Now, tomcat will return this annoying page in Tomcat's default format:

or
http://i41.photobucket.com/albums/e265/phlylbucket/tomat400error.jpg
Note that the reason this page appears has nothing to do with my web appli and I cannot prevent this from happening (except perhaps putting the /login.jsp under WEB-INF). It is all about Tomcat's built-in behaviour related to the above operation.

What I want is to replace this "ugly" page with my own custom designed page. It seems that for this particular example, I need to declare:

<error-code>400</error-code>
<location>/error400.jsp</location>

This works because this particular example return error code 400. But the problem is how can I tell what other operations would cause Tomcat to display other error code!
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are so obsessed by HTTP error codes, declare all possible error codes and redirect them to your own page.
As I said, they are all listed here :
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Most frequents may be 401,403,404,500

If you are getting a 400, this may be a problem with your program.
You might have to think how to fix it, instead of trying to redirect every error codes to a custom error page.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic