Extend the answers of Sotiros and Jhadesdew. If you use Java Config (for example, in Spring Boot), you can configure DispatchServlet to enable the OPTIONS request by configuring @Bean as follows:
@Bean public DispatcherServlet dispatcherServlet() { DispatcherServlet servlet = new DispatcherServlet(); servlet.setDispatchOptionsRequest(true); return servlet; }
Then I created a static helper that adopts the HttpMethods tactic as follows:
public static ResponseEntity<Void> allows(HttpMethod... methods) { HttpHeaders headers = new HttpHeaders(); Set<HttpMethod> allow = new HashSet<>(); for(HttpMethod method: methods){ allow.add(method); } headers.setAllow(allow); return new ResponseEntity<>(headers, HttpStatus.NO_CONTENT); }
This makes it easy to create your own OPTIONS displays:
@RequestMapping(method = RequestMethod.OPTIONS) ResponseEntity<Void> getProposalsOptions() { return allows(HttpMethod.GET, HttpMethod.OPTIONS); }
Although I think it makes sense that Spring MVC can automatically respond to OPTIONS , you cannot do this through Interceptor , but perhaps through a custom DispatcherServlet .
The advantage of writing your own OPTIONS answer is that it makes sense to configure OPTIONS in some cases based on user roles. For example, an unauthenticated API user can get Allow GET, OPTIONS , but the administrator will get the full API Allow GET, PUT, DELETE, OPTIONS . You set up the answer based on exploring user roles when calling OPTIONS .
source share