Access-Control-Allow-Methods

Применение

Прежде чем отправить кросс-доменный запрос с непростым методом, браузер выполняет предварительный запрос OPTIONS. Заголовок Access-Control-Request-Method в предварительном запросе указывает, какой метод собирается использовать клиент. Сервер отвечает заголовком Access-Control-Allow-Methods, подтверждая, какие методы принимаются для целевого ресурса.

Простые методы (GET, HEAD и POST) всегда разрешены протоколом CORS и, строго говоря, не требуют перечисления здесь. Явное их перечисление — распространённая практика, которая делает политику сервера понятной с первого взгляда.

Несколько методов перечисляются списком через запятую.

Список имён методов

Набор имён методов HTTP через запятую, которые сервер принимает для кросс-доменного доступа.

Access-Control-Allow-Methods: GET, POST, PUT, DELETE

* (подстановочный знак)

Звёздочка работает как подстановочный знак для запросов без учётных данных, разрешая любой метод.

Access-Control-Allow-Methods: *

Примечание

Для запросов с учётными данными подстановочный знак * трактуется как литеральная строка, а не как подстановочный знак. При наличии учётных данных каждый разрешённый метод должен быть перечислен явно.

Пример

Предварительный запрос выясняет, разрешён ли метод PUT. Сервер подтверждает несколько методов.

Запрос

OPTIONS /api/resource/42 HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: PUT

Ответ

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 7200

Более строгий сервер разрешает только GET и POST.

Access-Control-Allow-Methods: GET, POST

Диагностика

Сбои предварительного запроса, связанные с методами HTTP, блокируют сам кросс-доменный запрос ещё до того, как сервер обработает задуманную операцию.

В консоли выводится “Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.” Сервер не включил запрошенный метод в значение Access-Control-Allow-Methods. Добавьте недостающий метод в ответ на предварительный запрос. В nginx: add_header Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH”; В Apache: Header set Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH”

В ответе на предварительный запрос заголовок отсутствует полностью. Обработчик OPTIONS существует, но не возвращает Access-Control-Allow-Methods. Убедитесь, что маршрут предварительного запроса устанавливает этот заголовок наряду с Access-Control-Allow-Origin и Access-Control-Allow-Headers. Отсутствие заголовка с методами заставляет браузер отклонить любой непростой метод.

Подстановочный знак * не работает с запросами, содержащими учётные данные. Когда Access-Control-Allow-Credentials имеет значение true, подстановочный знак трактуется как литеральная строка * и не соответствует ни одному методу. В конфигурациях с учётными данными перечисляйте каждый разрешённый метод явно.

Сервер возвращает 405 Method Not Allowed при предварительном запросе. У сервера нет маршрута, обрабатывающего OPTIONS для целевого URL, поэтому запрос попадает на универсальный обработчик, который отклоняет метод. Добавьте обработчик OPTIONS к маршруту. В Express: app.options(‘/api/resource’, cors()). В Django промежуточное ПО django-cors-headers обрабатывает OPTIONS автоматически после установки. В nginx добавьте блок if ($request_method = OPTIONS) либо используйте limit_except, чтобы разрешить OPTIONS для этой location.

Фреймворк сам обрабатывает OPTIONS, но не добавляет заголовки CORS. Некоторые фреймворки отвечают на OPTIONS кодом 200 или 204 и обычным заголовком Allow с перечнем поддерживаемых методов, но не прикрепляют никаких заголовков CORS. Браузер считает такой предварительный запрос неудачным, поскольку Access-Control-Allow-Methods отсутствует. Настройте промежуточное ПО CORS так, чтобы оно перехватывало запросы OPTIONS до встроенного обработчика фреймворка. В Spring Boot зарегистрируйте bean CorsFilter. В ASP.NET вызовите services.AddCors() с нужной политикой до app.UseRouting().