здесь уместно Почему бы не использовать это?

код состояния должен возвращать хорошо написанный HTTP-сервер, когда он получает предварительную проверку CORS (OPTIONS) запрос?

200, 204 или что-то другое?

Должен ли код состояния отличаться в случае, если источник разрешен (и соответствующие заголовки будут установлены) или не разрешен (и заголовки CORS не будут установлены или не будут соответствовать источнику)?

Ответы на вопрос(1)

Решение Вопроса

200.

Немного более общего: вы должны просто отправить тот же код состояния для предварительной проверки CORSOPTIONS запрос, что вы отправите обратно для любого другогоOPTIONS запрос. Соответствующие спецификации не требуют и не рекомендуют ничего более этого.

Что касается соответствующих спецификаций: спецификации Fetch наhttps://fetch.spec.whatwg.org/ где определены требования к протоколу CORS, и он говорит, что статус может быть любым в диапазоне200-299.

Это изCORS-preflight алгоритм выборки, у которого естьшаг, говорящий, что это может быть любой «нормальный статус»:

Если проверка CORS длязапрос а такжеответ возвращает успех иответСтатус
ок статус, запустите эти подшаги:…

А что касается «нормального статуса», спецификация гласит:

ок статус любой статус в диапазоне200 в299включительно.

Помимо этого, однако, спецификация Fetch не рекомендует какой-либо конкретный статус в200-299.

Другой важной спецификацией здесь является спецификация HTTP 1.1, в которой есть раздел, определяющий семантику всех кодов состояния ответа HTTP, и внутри него:конкретный раздел, который определяетУспешный 2xx коды.

И в этом разделе естьопределенный раздел для200 ОК, который говорит это:

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 ответы - но, насколько я вижу, на самом деле нет никакого смысла. Это потому что:

в отличие от некоторых других методов, спецификация HTTP не определяет использованиеOPTIONS полезная нагрузкапоэтому на практике клиенты не ожидают, что какая-либо полезная нагрузка (контент) вернется заOPTIONS (и не будет ничего делать с любой полезной нагрузкой, которая вернулась)

... так что, насколько я понимаю, нет никакой практической цели в использовании конкретного204 код состояния вOPTIONS ответ явно сказать клиентам, что нет никакой полезной нагрузки.

Вполне возможно, что я могу ошибаться, и есть какой-то нюанс, который мне не хватает. Но я так не думаю.

Должен ли код состояния отличаться в случае, если источник разрешен (и соответствующие заголовки будут установлены) или не разрешен (и заголовки CORS не будут установлены или не будут соответствовать источнику)?

Нет, я не думаю, что это должно быть иначе. Я не знаю, какой стандартный код, кроме200 или же204 Вы могли бы использовать в любом случае - но независимо от этого, спецификации не требуют, чтобы он был каким-то другим, и не определяют никакого другого использования, если оно есть. И подумайте: что любой существующий клиентский код будет делать по-другому из-за различий в кодах состояния для этих двух случаев?

Если ответ на этот вопрос"Ничего"Насколько я понимаю, нет смысла делать это иначе.

Учитывая все вышеизложенное, суть заключается в следующем: просто отправить200 OK для предполетной подготовки CORSOPTIONS ответы. Отправка любого кода, кроме просто200 OK не является необходимым или полезным.

 blz19 мар. 2018 г., 13:53
204 NO CONTENT здесь уместно Почему бы не использовать это?

Ваш ответ на вопрос