[jboss-jira] [JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned

[Aaron Ogburn (JIRA)]

    [ https://issues.jboss.org/browse/JBWEB-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992017#comment-12992017 ] 

Aaron Ogburn commented on JBWEB-301:
------------------------------------

Let me note what happens specifically with DELETE/PUT and PATCH requests  First, here's what occurs with DELETE/PUT requests:

1) filter sends 405
2) StandardHostValve tries to serve custom error page, forwarding to custom 405 page.
3) Static 405 error page is served by org.apache.catalina.servlets.DefaultServlet.  It is still serving the original method for the forwarded error page request (DELETE or PUT).  DefaultServlet provides 403 in its doPut/doDelete implementations. So the put/delete to the static page gets a 403 in the end from the custom error page.


And now for PATCH requests:

1) filter sends 405
2) StandardHostValve tries to serve custom error page, forwarding to custom 405 page.
3) Static 405 error page is served by org.apache.catalina.servlets.DefaultServlet.  It is still serving the original method for the forwarded error page request (PATCH).  DefaultServlet extends javax.servlet.http.HttpServlet and does not override the HttpServlet.service method.  HttpServlet.service does not recognize the PATCH request method, and so it provides a 501/method not implemented response.


So in both cases, JBoss forwards the request to the custom error page, and the result of that forwarded request sets the end response code, overriding what your filter set.  Note the following portion from the servlet spec (JSR 315, Section 10.9.1):
...
 If the location of the error handler is a servlet or a JSP page:
 * The original unwrapped request and response objects created by the container are passed to the servlet or JSP page.
 * The request path and attributes are set as if a RequestDispatcher.forward to the error resource had been performed.
...

So we should expect the request to be forwarded to the error pages, which are handled by the DefaultServlet, and we should expect the end custom error page response from the DefaultServlet to override the filter's set 405.  It looks like everything is working as intended here and there is no actual bug, although the end result is not your desired result.  Your complaint would actually be against the servlet spec itself and not JBossWeb, which is just following the spec.

> When custom error pages are used in web.xml wrong status codes are returned
> ---------------------------------------------------------------------------
>
>                 Key: JBWEB-301
>                 URL: https://issues.jboss.org/browse/JBWEB-301
>             Project: JBoss Web
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: JBossWeb-7.2.1.GA
>         Environment: JBoss EAP 6.1.1
> Red Hat Linux 6.1
> CamelServlet 2.13.0
>            Reporter: Troy Longo
>            Assignee: Remy Maucherat
>
> I have the following code in my ServletFilter
> if(request instanceof HttpServletRequest)
>         {
>             isHttpRequest = true;
>         
>             if(!(((HttpServletRequest)request).getMethod().equals("POST")))
>             {
>                 ((HttpServletResponse)response).sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
>                 return;
>             }
>         }
> When I send a GET request, everything works fine and I am receive a response with a 405 status code. However when I send a PUT or DELETE, I receive a 403 and 501 status code respectively. I have debugged through my code and verified that I am hitting the same line above in my code. What I noticed is that this code was working nicely until I added some custom error pages into my web.xml. My web xml error page definitions are as follows. Removing these custom error pages from the web.xml cause the code to work as expected.
> <!--<error-page>
>             <error-code>500</error-code>
>             <location>/WEB-INF/500Error.html</location>
>     </error-page>
>     <error-page>
>             <error-code>404</error-code>
>             <location>/WEB-INF/404Error.html</location>
>     </error-page>
>     <error-page>
>             <error-code>413</error-code>
>             <location>/WEB-INF/413Error.html</location>
>     </error-page>
>     <error-page>
>             <error-code>405</error-code>
>             <location>/WEB-INF/405Error.html</location>
>     </error-page>-->



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)