Content Application Developer Manual / Version 2110
Table Of Contents
So far it is assumed that a request will be handled by the DispatcherServlet and
error handling can be implemented as part of the application. This is not always true, either
because the web server forwards requests to the servlet container which do not map to the
application or the DispatcherServlet, or because any of the components in the
request processing chain becomes unavailable, or cannot communicate with the next component.
As a fallback for these cases, static error pages should be installed in all components in the request processing chain for a consistent user experience:
Static default error pages can be configured in the application's deployment descriptor itself as described in Java Servlet Specification 3.0. For instance, these will respond to otherwise unhandled error conditions or requests to unmapped URLs. Tomcat will only fallback to these defaults error pages, if the application does not handle an exception or sets an error HTTP status code with an empty body in the response.
A web server configured as a reverse proxy to forward requests to a servlet container should at least be configured to return static error pages for cases when a request cannot be forwarded, the servlet container is not available, or there is a timeout. Apache HTTP Server provides the ErrorDocument directive for this purpose.
In a more elaborate setup with load balancers, HTTP accelerators, or content delivery networks, each such stage should be able to deliver static error pages should the downstream stage become unavailable.
