Какой код состояния должен возвращать хорошо написанный HTTP-сервер, когда он получает предварительный запрос CORS (OPTIONS)?
200, 204 или что-то еще?
Должен ли код состояния быть другим в случае, если источник разрешен (и соответствующие заголовки будут установлены) или не разрешен (и заголовки CORS не будут установлены или не будут соответствовать источнику)?
Суть в том, что просто используйте 200.
В более общем плане: вы должны просто отправить тот же код состояния для предварительного запроса CORS OPTIONS, который вы отправили бы для любого другого запроса OPTIONS. Соответствующие спецификации не требуют и не рекомендуют ничего большего.
Что касается соответствующих спецификаций: спецификация Fetch на https://fetch.spec.whatwg.org/ здесь определяются требования к протоколу CORS, и в нем говорится, что статус может быть любым в диапазоне 200-299.
Это из алгоритма предварительной выборки CORS, который имеет шаг, говорящий, что это может быть любой статус "ok":
Если проверка CORS для запроса и ответа завершается успешно, а статус ответа равен
статус ok, выполните следующие подшаги: …
А что касается «нормального статуса», спецификация говорит следующее:
Статус ok — это любой статус в диапазоне от
200до299включительно.
Помимо этого, спецификация Fetch не рекомендует какой-либо конкретный статус в пределах 200-299.
Другой важной спецификацией здесь является спецификация HTTP 1.1, в которой есть раздел, определяющий семантику всех кодов состояния ответа HTTP, и внутри него конкретный раздел, определяющий успешные коды 2xx.
В этом разделе есть специальный раздел для 200 OK< /a>, в котором говорится следующее:
The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:
…
OPTIONS a representation of the communications options;
Таким образом, ответ на ВАРИАНТЫ предварительной проверки CORS должен быть следующим:
Access-Control-Allow-Methods и Access-Control-Allow-Headers заголовки ответа)Это то, что 200 OK определяется спецификацией HTTP, поэтому вы можете Остановись прямо там.
Но если вы прочитаете остальные 2xx кодов в этом разделе, вы сможете подтвердите, что семантика ни одного из них не имеет смысла для ответа OPTIONS, за исключением 204 No Content.
Теперь, что касается 204 No Content, нет ничего плохого в использовании его для OPTIONS ответов, но, насколько я понимаю, в этом нет никакого смысла. Это потому что:
OPTIONSOPTIONS (и ничего не будут делать с любой полезной нагрузкой, которая вернулась)…поэтому, насколько я понимаю, нет практической цели использовать определенный код состояния 204 в ответе OPTIONS, чтобы явно сообщить клиентам, что полезной нагрузки нет.
Хотя, возможно, я ошибаюсь, и я упускаю какой-то нюанс. Но я так не думаю.
Должен ли код состояния быть другим в случае, если источник разрешен (и соответствующие заголовки будут установлены) или не разрешен (и заголовки CORS не будут установлены или не будут соответствовать источнику)?
Нет, я не думаю, что должно быть по-другому. Я не знаю, какой стандартный код, кроме 200 или 204, вы могли бы использовать в любом случае, но независимо от этого спецификации не требуют, чтобы он отличался, и не определяют никакого другого использования, если это так. И подумайте об этом: что любой существующий клиентский код будет делать по-другому из-за разницы в кодах состояния для этих двух случаев?
Если ответ на этот вопрос Ничего, насколько я понимаю, нет смысла что-то менять.
Учитывая все вышеизложенное, суть такова: просто отправьте 200 OK ответов CORS preflight OPTIONS. Отправка любого кода, кроме 200 OK, не нужна и не полезна.
204 NO CONTENT здесь уместно. Почему бы не использовать это?
- person Louis Thibault; 19.03.2018
Я использовал 204. Теперь он больше не работает в кроссбраузерном режиме. Используйте 200. Firefox начал отклонять запросы CORS, если 204 получен в предварительной проверке. Я потратил почти 2 часа на его отладку.
Урок, который нужно усвоить: если вы сомневаетесь в веб-стандартах, не выбирайте то, что имеет смысл с точки зрения спецификации (например, 204 для отсутствия контента) ... выбирайте то, что делает большинство людей (простой/глупый выбор)
