Bug 1322998

Summary: [GSS] (6.4.z) HTTP request using OPTIONS resets the HTTP response
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: William Antônio <wsiqueir>
Component: RESTEasyAssignee: Bartek Spyrko-Smietanko <bspyrkos>
Status: CLOSED CURRENTRELEASE QA Contact: Peter Mackay <pmackay>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.4.0CC: bmaxwell, bspyrkos, cdewolf, daniel.zigerlig, pmackay, rstancel, weli
Target Milestone: CR1   
Target Release: EAP 6.4.13   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-03 16:46:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1386033, 1386335    

Description William Antônio 2016-03-31 22:04:38 UTC
Description of problem:

If a request is made to a JAX-RS resource using the OPTIONS HTTP method and the an OPTIONS method is not implemented, a DefaultOptionsMethodException[1] exception will be thrown so RESTEasy can return a default response that fulfills the JAX-RS 1.1 specification section 3.3.5.

Users can use an exception mapper to customize the response. The problem is that when users uses a servlet web filter to, for example, configure the response headers, this information will be lost, since resteasy reset the HTTP response when an exception is thrown[3] ( see [4] since DefaultOptionsMethodException is an instance of Failure).

This is a bug to address this problem: resteasy should not reset the response when a DefaultOptionsMethodException is thrown. 

[1] https://docs.jboss.org/resteasy/docs/2.3.1.GA/javadocs/org/jboss/resteasy/spi/DefaultOptionsMethodException.html
[2] https://jsr311.java.net/nonav/releases/1.1/spec/spec.html
[3] https://github.com/resteasy/Resteasy/blob/Branch_2_3/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/SynchronousDispatcher.java#L446
[4] https://github.com/resteasy/Resteasy/blob/Branch_2_3/resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/SynchronousDispatcher.java#L259

Version-Release number of selected component (if applicable):


How reproducible:

always 
Steps to Reproduce:
1. Create a jax-rs web app with a jax-rs resource and a web filter
2. the resource should have have a method with the @OPTIONS annotation:

import javax.ws.rs.GET;
import javax.ws.rs.Path;

@Path("resource")
public class MyResource {

	@GET
	public String get() {
		return "ok";
	}

}

3. The web filter should set something in the response, let's say an http header:

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebFilter(urlPatterns = "/*")
public class SampleFilter implements Filter {

	@Override
	public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain chain) throws IOException, ServletException {
		HttpServletRequest req = (HttpServletRequest) request;
		HttpServletResponse resp = (HttpServletResponse) response;
		System.out.println("Invoking Filter. Method: " + req.getMethod());
		resp.setHeader("X-test-filter", "HTTP header set in Filter");
		chain.doFilter(request, response);
	}
     // other stuff

}

4. Send a request using the HTTP method OPTIONS to the resource endpoint

Actual results:
the X-test-filter header will not be present

Expected results:
The header should be present and the response should not be reset 

Additional info:

Perhaps the class DefaultOptionsMethodException should not extend Failure and it should be handled differently?

The workaround is to set the headers for OPTIONS method in a exception mapper for exception DefaultOptionsMethodException.

Comment 4 Radovan STANCEL 2016-12-05 15:35:59 UTC
Merged

Comment 5 Peter Mackay 2017-01-05 15:28:57 UTC
Verified with EAP 6.4.13.CP.CR1

Comment 6 Petr Penicka 2017-02-03 16:46:05 UTC
Released with EAP 6.4.13 on Feb 02 2017.