|Summary:||Global error page is not handled|
|Product:||Tomcat 7||Reporter:||balusc <balusc>|
|Component:||Servlet & JSP API||Assignee:||Tomcat Developers Mailing List <dev>|
|Severity:||enhancement||CC:||jens.borgland, jks, ljelinek, sutanu_g|
Description balusc 2011-11-04 14:15:58 UTC
Comment 1 Mark Thomas 2011-11-04 19:41:49 UTC
There is no "new Servlet 3.0 global error page" I can find references to in the Servlet 3.0 specification. Tomcat uses error pages with some of the applications that ship with Tomcat and error pages work correctly in those applications. Please feel free to re-open this issue but if you do you are going to have to provide a lot more detail else it will simply be re-closed as invalid. You'll need to provide the full steps to reproduce this issue on a clean install of the latest Tomcat 7 release. Providing the simplest possible web application (with source code) that demonstrates the issue is one way to do this.
Comment 2 balusc 2011-11-04 21:01:09 UTC
The <exception-type> and <error-page> entries are now *optional* by XSD, before either one of them was required.
Comment 3 balusc 2011-11-04 21:05:57 UTC
(where's the edit comment link?) Sorry, in the previous comment I meant to say <error-code> instead of <error-page>. Also the figure 14-10 in Servlet 3.0 spec identifies those options with a dotted line which means that they are optional.
Comment 4 Sutanu Ghosh 2012-03-30 19:43:24 UTC
I have tested this on Apache Tomcat/7.0.23 If I declare following without <error-code> or <exception-type> : <error-page> <location>/error</location> </error-page> It does not take effect, i.e. /error does not get invoked when any http error or exception from servlet occurs. Not sure if this is a valid declaration per servlet 3.0 spec. But if supported it's very useful to allow a "catch-all" error handler.
Comment 5 Mark Thomas 2012-03-30 19:53:33 UTC
There is no reference in section 10.9.2 for the behaviour described. That it works in Glassfish does not make it part of the specification. There is no explanation of why those elements are now optional. Nor does section 10.9.2 explain how the case where neither is provided should be handled.
Comment 6 Rossen Stoyanchev 2012-03-30 20:13:58 UTC
Mark, what's the process of getting a clarification? This is a useful feature for example in REST-ful web service scenarios where the behavior of ServletResponse.sendError() to send HTML is not desirable: http://blog.newsplore.com/2010/08/04/restful-error-handling-with-tomcat-springmvc
Comment 7 Keith Donald 2012-03-30 20:17:10 UTC
The XSD for Servlet 3.0's web.xml clearly allows a <error-page> element containing only a <location> sub-element. Older versions of the XSD do not. This is an indication this is a Servlet 3.0 feature. This feature is useful. Most REST API implementations need to report unhandled errors the same way: by returning a JSON body containing the error message (reason). Having to define a error-page entry for each error code that may be set by the application via HttpServletResponse#sendError is more work than it should be. Having a single error-page entry for a default error handler is a lot simpler and future proof. I consider this a bug in Tomcat 7. Shoot me down if you want!
Comment 8 Mark Thomas 2012-03-30 20:19:33 UTC
e-mail the Servlet EG (of which I am a member but only since JSR 340 so I do not have access to the thinking behind the changes in JSR 315). You'll need to join the JSR-340 users mailing list. See http://java.net/projects/servlet-spec
Comment 9 Mark Thomas 2012-03-31 12:39:46 UTC
There is no bug here since there is no documented behaviour in the specification (nor the Javadoc, nor the XSD) that Tomcat is not implementing. The change in the XSD is indicative of something but there is zero clarity on what that might be. The surrounding comment text in the XSD gives no clues. Neither, as I pointed out earlier, does the spec document. I can see the usefulness of this feature but (absent clarification from the EG) it would be as a Tomcat specific extension. I am therefore moving this to an enhancement request. Enhancement requests with patches tend to get addressed sooner than those with out.
Comment 10 Filip Hanik 2012-04-02 14:36:55 UTC
Mark, I agree with your assessment. It is an enhancement, and a useful one. The spec itself is, and will remain, fairly limited on feature set, and as Tomcat evolves nothing prevents us from adding usability to the container.
Comment 11 Libor Jelinek 2012-04-13 10:43:15 UTC
Maybe useful to "is/isn't part of Servlet 3.0" discussion: https://blogs.oracle.com/arungupta/entry/totd_136_default_error_page But no matter if it is "de iure" part of spec, this feature is very handy and I hope that will be added soon.
Comment 12 Jens Borgland 2012-06-19 17:29:26 UTC
I think this would be a very good thing to have from a security perspective - makes it very easy to reduce the amount of error information that is disclosed by specifying one single error page that handles all errors and returns some generic message.
Comment 13 Mark Thomas 2012-06-30 13:14:56 UTC
There is a number of circumstantial pieces of evidence that all suggest the Servlet 3.0 EG intended to include this in the 3.0 specification, updated the XSD for web.xml accordingly and then forgot to actually add the feature to the specification document. I have added support for this to trunk and 7.0.x and it will be included in 7.0.29 onwards.
Comment 14 Shivakumar P 2012-12-17 08:18:00 UTC
The fix is said to have gone into 7.0.29 "I have added support for this to trunk and 7.0.x and it will be included in 7.0.29 onwards." I tested this on 7.0.30.Iam still facing this issue.
Comment 15 Konstantin Kolinko 2013-01-10 02:46:22 UTC
(In reply to comment #14) > The fix is said to have gone into 7.0.29 > "I have added support for this to trunk and 7.0.x and it will be included in > 7.0.29 onwards." > > I tested this on 7.0.30.Iam still facing this issue. Works for me, tested current 7.0.x trunk (it is near to be tagged as 7.0.35). Whatever does not work for you, you have to provide the details, including the steps required to reproduce the issue. If it is indeed a bug, open a new issue.
Comment 16 Konstantin Kolinko 2013-01-10 02:49:45 UTC
Created attachment 29837 [details] globalerrortest.war For the record: a sample web application that I used to test that it DOES work with the current 7.0.x. Assessing index.jsp triggers a compilation error, and the error page is displayed. I should also note that the implementation for this feature ( r1355734 ) did include a test case.
Comment 17 Libor Jelinek 2013-03-17 09:48:29 UTC
Potential reason to reopen this: Having the following web.xml still end up with showing Tomcat default error page. Is it intended behavior or a bug? <servlet> <!-- throws some exception --> <servlet-name>ThrowerServlet</servlet-name> <servlet-class>org.example.ThrowerServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>ThrowerServlet</servlet-name> <url-pattern>/*</url-pattern> </servlet-mapping> <error-page> <location>/WEB-INF/global-error-page.jsp</location> </error-page> I assume that scenario here is the following: 1. ThrowerServlet causes an exception 2. Tomcat issue error dispatch 3. But it is responded by ThrowerServlet (have catch-all URL pattern /*) which causes same exception again. 4. Tomcat present default error page I'm asking if error page should be matched by /*, i.e. effectively skipping error page to display and resulting in calling buggy servlet on /* again.
Comment 18 balusc 2013-03-17 14:35:39 UTC
@Libor: this is behaving as specified. Your servlet is mapped on an overly generic URL pattern of /* which thus also overrides among others the servletcontainer's builtin JspServlet which is listening on *.jsp which thus never get the chance to serve the JSP.