Bug 41007 - Can't define customized 503 error page
Summary: Can't define customized 503 error page
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-20 12:24 UTC by Veit Guna
Modified: 2022-03-15 20:52 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Veit Guna 2006-11-20 12:24:59 UTC
Hi.

I didn't find any way to customize a global 503 error page. Sure, that can't be
on  webapps level because when it's stopped it can't be reached. So it should
give a way to customize that default tomcat error page at least for 503 errors.

I've searched the web and mailing lists on this issue and no one got it solved.
Someone said it's hardcoded in
org.apache.catalina.valves.ErrorReportValve.report(). If that is the case, that
would be really bad.
Comment 1 Mark Thomas 2006-11-20 13:48:49 UTC
Bugzilla is not the forum to ask questions. Please post your question to the
Tomcat users mailing list.
Comment 2 Veit Guna 2006-11-20 14:40:16 UTC
I didn't find any question mark in my sentences, did you?

On the mailing list they say, it's hardcoded. It's surely no bug - but where can
I put feature requests then?
Comment 3 Mark Thomas 2006-11-20 15:00:34 UTC
I assumed there was an implied question "How do I set a global 503 error page?".

The reply to your post on the users list points you towards how to customise
this to use your own page.
Comment 4 Veit Guna 2006-11-20 15:05:27 UTC
Yes, errorReportValveClass should do the trick. Why is it so complicated for
just an easy task? Ok, where can I put feature requests? Then you can close this
one.
Comment 5 Mark Thomas 2006-11-20 15:14:34 UTC
To register this an enhancement request, I have re-opened this issue and set the
severity to enhancement. I also set a few other attributes.

Why is it like this? The current approach works and no one has felt the need to
change it.

Obviously, enhancement requests with patches that implement them are more likely
to make it into the codebase.
Comment 6 Mark Thomas 2011-12-20 20:35:11 UTC
This Tomcat 5 enhancement request has been moved to Tomcat 7 (the latest version) since Tomcat 5 development is limited and focussed on bugs and security issues whereas Tomcat 7 is still seeing new feature development.
Comment 7 Mark Thomas 2018-01-26 14:37:12 UTC
A decade plus on from when this was opened I'm planning on implementing a solution for this. The overall plan is:

- Pass errors that happen early in the processing chain to the app / the
  container to handle where we can

- Extend the ErrorReportValve to allow static pages to be defined for error
  codes and/or Exceptions.

Progress so far is (all in 9.0.x):
- I have refactoring the processing chain so we can pass errors.
- I have started to refactor the handling of individual errors to pass them when the
  occur.

This last point is throwing up various edge cases. Currently I am working on JSPs, TRACE and OPTIONS handling. I'm expecting the refactoring of the individual error cases to take a little while to sort out.
Comment 8 Veit Guna 2018-01-26 18:44:14 UTC
After a decade, reading my posts is embarassing in terms of politeness. My apologies. A little late - but better than never. Thanks you for finally looking into this :)!
Comment 9 Mark Thomas 2018-01-26 20:18:17 UTC
No worries. I've written far worse in my time.

Fixing this is turning up all sorts of interesting edge cases. I'm actually quite enjoying tackling it.

This is one I've kept coming back to from time to time but hadn't - until this time - found a way of tackling it that I was happy with. The clean up to the connector code that we've done since this was first raised back in the days of 5.x has certainly helped.
Comment 10 Mark Thomas 2018-02-08 15:15:50 UTC
A quick update.

I believe the refactoring to enable the application/container error handling to handle error reporting is complete. The errors that aren't processed this way are:
- any error that is so severe it requires the immediate closure of the network connection
- any error that occurs after the request/response has left the standard processing pipeline (i.e. once it is too late for the application error handling or the ErrorReportValve to do anything).

This has only been completed for 9.0.x and - given the refactoring involved - is unlikely to be back-ported.

Next up is extended in the ErrorReportValve to enable static pages to be used for given errors.
Comment 11 Mark Thomas 2018-02-14 10:18:45 UTC
The ability to specify a static error page for given status codes and/or exception types has now been added to the ErrorReportValve. It will be included in 9.0.6 onwards.
Comment 12 Mark Thomas 2022-03-15 20:52:32 UTC
Back-ported to 8.5.x for 8.5.78 onwards