Я знаю, что это немного устарело, но я нашел дополнительную информацию по этому вопросу, которая, я надеюсь, поможет другим в будущем.
Подход @RequestMapping (RequestMethod.OPTIONS) не будет работать сразу при использовании DispatcherServlet из коробки, поскольку его суперкласс FrameworkServlet сначала делегирует своему суперклассу HttpServlet, как отмечалось выше, который сканирует сервлет, чтобы увидеть, реализует ли он методы doXXX и соответственно устанавливают заголовок Allow. Но после вызова super.doOptions (...) он имеет следующие строки:
if (this.dispatchOptionsRequest) {
processRequest(request, response);
}
И есть setDispatchOptionsRequest (логическое значение), которое можно использовать для установки значения dispatchOptionsRequest в значение true. Только тогда DispatcherServlet передаст в контроллер запрос OPTIONS соответствующему аннотированному методу.
Мне нужно было сделать это, чтобы запрос OPTIONS мог возвращать разные значения в зависимости от полномочий текущего пользователя. Таким образом, создав подкласс DispatcherServlet и установив этот параметр в его конструкторе по умолчанию, я наконец смог получить вызов в моем контроллере для запросов http OPTIONS и обработать его самостоятельно.
И еще одна мысль: в этом методе контроллера вы можете объявить параметр типа HttpServletResponse, и Spring передаст вам экземпляр. После этого вы можете вызвать reset (), чтобы очистить уже установленный заголовок Allow и при необходимости свернуть свой собственный.
(Примечание. Аналогичная схема имеется в FrameworkServlet для поддержки http TRACE через setDispatchTraceRequest, если вы планируете получать эти запросы через методы контроллера, аннотированные @RequestMapping (RequestMethod.TRACE)).