Каков ожидаемый ответ на недопустимый запрос CORS?

В спецификации CORS не говорится о том, как серверы должны реагировать на недопустимые запросы CORS. Например, если запрос Origin недействителен, CORS spec утверждает: "завершите этот набор шагов. Запрос выходит за рамки этой спецификации" . Аналогичный язык существует для других случаев ошибок, таких как запрос недопустимых методов или заголовков.

Каким должен быть ожидаемый ответ в случае ошибок CORS? Я понимаю, что для разных серверов может потребоваться другое поведение. Но я ищу стандартный ответ или ответы, которые могут быть приемлемыми, если владельцу сервера все равно.

ОТВЕТЫ

Ответ 1

Да, я понимаю, что я отвечаю на свой вопрос, но здесь все идет. Я сделал некоторые исследования в этом, и кажется, что поведение падает на два лагеря:

1) Верните ошибку, если запрос CORS недействителен. Это маршрут, принятый фильтр Java CORS проект. Эта библиотека возвращает

  • 400 Плохой запрос для запросов, которые не соответствуют спецификации
  • 403 Запрещено для недопустимых истоков или заголовков.
  • 405 Метод Не разрешать недопустимые методы

2) Верните заголовки CORS в ответ и позвольте браузеру разобраться в деталях доступа. Это, по-видимому, гораздо более общий подход и используется API для Amazon S3, SoundCloud, FourSquare и Spotify (последние два API полезны только для поддержки простых запросов CORS). В этом случае сервер не выполняет проверку ошибок и просто возвращает заголовки CORS для поддерживаемого источника, метода и заголовков. Браузер все еще выполняет запрос, но если заголовки ответа CORS не соответствуют запросу пользователя, браузер не отвечает на него от пользователя.

Каждый из этих методов имеет свои плюсы и минусы. Метод № 1 более тесно связан с спецификацией CORS, но не предоставляет пользователю полезной информации отладки.

Метод № 2 дает более полное представление о поддерживаемых методах и заголовках. Это также проще реализовать, поскольку сервер возвращает одни и те же заголовки ответов, независимо от заголовков запросов. Однако это происходит за счет фактического выполнения запроса на стороне сервера, хотя браузер блокирует ответ от пользователя. Это может быть нежелательно для метода с побочными эффектами, таких как POST, PUT или DELETE, и подчеркивает тот факт, что CORS не следует использовать в качестве механизма аутентификации.

(Обратите внимание, что мои исследования выше ни в коем случае не являются исчерпывающими. Было сложно увидеть истинное поведение многих API-интерфейсов, поскольку они либо потребовали аутентификацию, либо заблокировали запрос на другом уровне для какой-либо другой ошибки, например, неподдерживаемый метод.)

Ответ 2

Я бы ожидал, что это будет зависеть от характера ошибки, но я бы ожидал некоторую ошибку 4xx, такую ​​как 403 (если запрос не прошел некоторые требуемые критерии) или 404 (если этот метод недоступен).

Ответ 3

Я просто хочу добавить к ответу Monsur. Есть еще одно поведение (то, которое в настоящее время используется S3):

  1. Чтобы отправлять заголовки ответа CORS, только если они соответствуют источнику запроса. В противном случае, вообще не отправляйте заголовки CORS, и пусть ваш браузер или любой другой клиент сам решит.

По крайней мере, так у меня работает.

Кроме того, когда дело доходит до Java, обычно отправляют 403. Эта ссылка на Java довольно старая, но фактический стандарт в Java, Spring, такой же. Смотрите мою ссылку здесь.