I'd like to intercept the OPTIONS request with my controller using Spring MVC, but it is catched by the DispatcherServlet. How can I manage that?
-
2For those on Spring Boot, this follow-up question may be useful: http://stackoverflow.com/questions/33331042/how-to-handle-http-options-requests-in-spring-boot – Jonik Oct 25 '15 at 22:19
5 Answers
I added some more detail to the Bozho answer for beginners. Sometimes it is useful to let the Spring Controller manage the OPTIONS request (for example to set the correct "Access-Control-Allow-*" header to serve an AJAX call). However, if you try the common practice
@Controller
public class MyController {
@RequestMapping(method = RequestMethod.OPTIONS, value="/**")
public void manageOptions(HttpServletResponse response)
{
//do things
}
}
It won't work since the DispatcherServlet will intercept the client's OPTIONS request.
The workaround is very simple:
You have to... configure the DispatcherServlet from your web.xml file as follows:
...
<servlet>
<servlet-name>yourServlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>dispatchOptionsRequest</param-name>
<param-value>true</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
...
Adding the "dispatchOptionsRequest" parameter and setting it to true.
Now the DispatcherServlet will delegate the OPTIONS handling to your controller and the manageOption() method will execute.
Hope this helps.
PS. to be honest, I see that the DispatcherServlet append the list of allowed method to the response. In my case this wasn't important and I let the thing go. Maybe further examinations are needed.

- 3,254
- 1
- 19
- 26

- 2,505
- 7
- 28
- 50
-
1but this does not work, if for example a handlermethod is registered at endpoint "/x/y". Now an OPTIONS-request to /x works but not to /x/y is there any option to solve this issue? meaning to add this OPTIONS-handling to all of the registered endpoints? I think about interceptors but is there any other way? – wrm Jun 18 '12 at 13:23
@RequestMapping(value="/youroptions", method=RequestMethod.OPTIONS)
public View getOptions() {
}
You should configure the dispatcherServlet by setting its dispatchOptionsRequest
to true

- 588,226
- 146
- 1,060
- 1,140
-
1actually it won't work since the DispatcherServlet will intercept the request and it will handle it. It should be configured the DispatcherServlet instead. I had a lot of pain with this issue, and currently I partially solved the problem. I wanted to post my solution for the community but... since I have less than 100 of reputation stackoverflow force me to wait 8 hours befor letting me answer my own questions. – MaVVamaldo Mar 01 '12 at 18:23
-
1yes it is the solution. I should have met you before, good god! XD However this is a "partial" solution because the DispatcherServlet will do "some work" before delegating your controller. Infact, even though you won't touch the "Allow" header it will be filled with a list of "allowed method". In my case it wouldn't be a problem but I suppose it is for someone else. – MaVVamaldo Mar 01 '12 at 18:34
-
Important update: OPTIONS requests will be supported by default as of Spring Framework 4.3, see https://jira.spring.io/browse/SPR-13130 for more details. – Sébastien Deleuze Apr 26 '16 at 22:39
As a quick supplement to the above 2 answers, here's how to enable dispatchOptionsRequest in a servlet 3 (no web.xml) environment as it took me a while to work out how to apply the answers above in a non-xml setup.
In a spring 3.2 / servlet 3 environment, you will have some variety of DispatcherServlet
initializer class which is the java equivalent of web.xml; in my case it's the AbstractAnnotationConfigDispatcherServletInitializer
. Adding the following code will enable dispatchOptionsRequest:
@Override
protected void customizeRegistration(Dynamic registration) {
registration.setInitParameter("dispatchOptionsRequest", "true");
}

- 2,011
- 2
- 18
- 22
I took the following approach:
Using Maven (or manually) pull in this dependancy:
<dependency>
<groupId>com.thetransactioncompany</groupId>
<artifactId>cors-filter</artifactId>
<version>1.3.2</version>
</dependency>
This has an implementation to capture all the inbound OPTIONS requests. Into the web.xml file add the following config:
<filter>
<filter-name>CORS</filter-name>
<filter-class>com.thetransactioncompany.cors.CORSFilter</filter-class>
<init-param>
<param-name>cors.supportedHeaders</param-name>
<param-value>Content-Type,Accept,Origin</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CORS</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
The problem I've seen with the /** approach is a more specific Controller implementation will override this.

- 3,254
- 1
- 19
- 26
For Spring without web.xml file, and based on Paul Adamson answer, I just set the parameter dispatchOptionsRequest
to true
into the dispatcher, to process the Options
method calls.
ServletRegistration.Dynamic dispatcher = container.addServlet("dispatcher", new DispatcherServlet(applicationContext));
dispatcher.setInitParameter("dispatchOptionsRequest", "true");
dispatcher.setLoadOnStartup(1);
dispatcher.addMapping("/*");

- 13,196
- 5
- 87
- 72