Какой код состояния должен иметь хорошо написанный HTTP-сервер, когда он получает запрос CORS preflight (OPTIONS)?
200, 204 или что-то еще?
Если код состояния отличается в том случае, если источник разрешен (и соответствующие заголовки будут установлены) или не разрешены (и заголовки CORS не будут установлены или не совпадут с началом)?
Суть в том, что просто используйте 200.
Немного больше: вы должны просто отправить тот же код статуса для запроса предпросмотра CORS OPTIONS, который вы отправите обратно для любого другого запроса OPTIONS. Соответствующие спецификации не требуют или не рекомендуют ничего более.
В соответствии с соответствующими спецификациями: спецификация Fetch в https://fetch.spec.whatwg.org/ - это то, где определены требования к протоколу CORS, и говорится о статусе может быть любым в диапазоне 200 - 299.
Это из алгоритм CORE-preflight fetch, который шаг говоря, что это может быть любой статус "ok" :
Если проверка CORS для запроса и ответа возвращает статус успеха и ответов - статус ok, выполните следующие подшаги:...
И что касается состояния "ok status", спецификация говорит следующее:
Статус ok - это любой статус в диапазоне от
200до299включительно.
Помимо этого, спецификация Fetch не рекомендует какой-либо конкретный статус в пределах 200 - 299.
Другим соответствующим спецификатором здесь является спецификация HTTP 1.1, в которой есть раздел, определяющий семантику всех кодов состояния HTTP-ответа, и внутри этого конкретный раздел, который определяет успешные коды 2xx.
И в этом разделе theres конкретный раздел для 200 OK, в котором говорится следующее:
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, но, насколько я вижу, theres также не имеет никакого смысла. То потому что:
OPTIONS полезной нагрузкиOPTIONS (и ничего не сделает с какой-либо полезной нагрузкой, которая вернулась).... насколько я вижу, нет никакой практической цели в использовании определенного кода состояния 204 в ответе OPTIONS для явного указания клиентам без полезной нагрузки.
Возможно, я могу ошибаться, и у меня есть какой-то нюанс. Но я так не думаю.
Если код состояния отличается в том случае, если источник разрешен (и соответствующие заголовки будут установлены) или не разрешены (и заголовки CORS не будут установлены или не совпадут с началом)?
Нет, я не думаю, что это должно быть иначе. Я не знаю, какой стандартный код, кроме 200 или 204, вы могли бы использовать в любом случае, но независимо от этого спецификации не требуют, чтобы он был каким-либо другим и не определял любое другое использование, если оно есть. И подумайте над этим: какой существующий клиентский код будет делать по-другому из-за какой-либо разницы в кодах состояния для этих двух случаев?
Если ответ на этот вопрос "Ничто", насколько я вижу, нет смысла делать его другим.
Учитывая все вышесказанное, нижняя строка: просто отправьте 200 OK для ответов CORS preflight OPTIONS. Отправка любого кода, кроме только 200 OK, не нужна или не нужна.