Bug 1315936 - [GSS](6.4.z) Custom error page is ignored for 405 Method Not Allowed
[GSS](6.4.z) Custom error page is ignored for 405 Method Not Allowed
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: RESTEasy, Web (Show other bugs)
Unspecified Unspecified
high Severity unspecified
: CR1
: EAP 6.4.10
Assigned To: Chao Wang
Peter Mackay
Depends On:
Blocks: 1324261 eap6410-payload
  Show dependency treegraph
Reported: 2016-03-08 22:45 EST by Osamu Nagano
Modified: 2017-01-17 08:03 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xxx.yyy.zzz.war (3.45 KB, application/zip)
2016-03-09 02:03 EST, Osamu Nagano
no flags Details

  None (edit)
Description Osamu Nagano 2016-03-08 22:45:39 EST
Description of problem:
A custom error page is configured in web.xml for each HTTP error status but the behaviour is inconsistent.  For example, the page is returned for "404 File Not Found" and "415 Unsupported Media Type", but not for "405 Method Not Allowed".  It seems the response has been already committed in the 405 case.

Version-Release number of selected component (if applicable):
EAP 6.3.0 (resteasy-jaxrs-2.3.8.Final-redhat-3.jar)
EAP 6.4.6 (resteasy-jaxrs-2.3.12.Final-redhat-1.jar)
EAP 7.0.b (resteasy-jaxrs-3.0.13.Final-redhat-1.jar)
* EAP 7 behaves in more different way.

How reproducible:

Steps to Reproduce:
1. Deploy attached xxx.yyy.zzz.war.
2. Try the following URLs.

curl -i  http://localhost:8080/test/xyz/foo -X POST -H 'Content-Type:application/json'
 => 200 OK request

curl -i  http://localhost:8080/test/xyz/foo -X POST 
 => 415 Unsupported Media Type with the custom error page

curl -i  http://localhost:8080/test/xyz/foo1 -X POST -H 'Content-Type:application/json'
 => 404 File Not Found with the custom error page

curl -i  http://localhost:8080/test/xyz/foo -X GET
 => 405 Method Not Allowed with the default error page

Expected results:
The custom error page should be returned for 405 too.

Additional info:
If you use ExceptionMapper like this, the returned contents can be customized.  
package xyz;

import org.jboss.resteasy.spi.MethodNotAllowedException;

import javax.ws.rs.core.Response;
import javax.ws.rs.ext.Provider;
import javax.ws.rs.ext.ExceptionMapper;

public class CustomErrorPage implements
        ExceptionMapper<MethodNotAllowedException> {

    public Response toResponse(MethodNotAllowedException exception) {
        System.out.println("Custom Exception " + exception.getMessage());
        return Response.status(405).entity("test").build();
Comment 4 Osamu Nagano 2016-03-09 02:03 EST
Created attachment 1134399 [details]

Hi, I'm very sorry that I forgot to attach the war file, xxx.yyy.zzz.war.
Comment 5 Chao Wang 2016-03-10 05:09:24 EST
In JBossWeb, https://source.jboss.org/browse/JBossWeb/branches/7.5.x/src/main/java/org/apache/catalina/core/StandardHostValve.java?hb=true#to424 When http status code is 405, it will return immediately without finding any customer error page at line: 

       /* Only look for error pages when isError() is set.

         * isError() is set when response.sendError() is invoked. This

         * allows custom error pages without relying on default from

         * web.xml.


       if (!response.isError())


I can see the custom error page for status code 405 once I comment out the "return;"

$ curl -i  http://localhost:8080/test/xyz/foo -X GET

HTTP/1.1 405 Method Not Allowed
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"117-1455094050000"
Last-Modified: Wed, 10 Feb 2016 08:47:30 GMT
Content-Type: text/html
Content-Length: 117
Date: Thu, 10 Mar 2016 09:44:43 GMT

<!DOCTYPE html>
<meta charset="UTF-8">
<body>.<!-- J --></body>

But, it seems this is an expected action when response.isError() value is false as comments above the codes. More investigation is needed here, and I add web as second component for this bugzilla.
Comment 7 Mike McCune 2016-03-28 18:24:40 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 9 Peter Mackay 2016-08-29 08:29:47 EDT
Verified with EAP 6.4.10.CP.CR2
Comment 10 Petr Penicka 2017-01-17 08:03:53 EST
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.
Comment 11 Petr Penicka 2017-01-17 08:03:56 EST
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Note You need to log in before you can comment on or make changes to this bug.