Является ли использование заголовка местоположения в ответе HTTP 202 RFC-совместимым?

Наконец, я получил ответ от Р. Филдинга:

202 – статус успеха. Указанный указатель – это просто гипертекст в теле ответа . 303 следует отправить, если вы хотите использовать Location для перенаправления клиента на другой ресурс. Результатом перенаправленного запроса может быть 202.

….Рой

Таким образом, заголовок Location не должен использоваться в ответе 202 Accepted . Ребята из PHP сделали правильную интерпретацию.

Edit March, 2017: Извините, я забыл добавить другие сообщения, которые мы обменяли в той же теме в тот момент, поэтому я отправляю сейчас запись:

me: В разделе 4.1 RFC 7240 автор (J. Snell) приводит пример, используя заголовок Location в ответе «Принимаемый ответ» 202. Он не прав? Это похоже на то, как многие люди понимают это поведение из RFC 7231. Можете ли вы выслать мне какую-либо ссылку на эту спорную проблему?

Рой: Пример дается без инструкций, поэтому он не ошибается, потому что он не говорит, что это значит. Место может быть отправлено в любом сообщении. То, что это означает, определяется только для определенных кодов состояния.

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

PHP ошибочно полагает, что Location используется только в ответах 201 и 3xx, но это разрешено, потому что его внутренний API не является HTTP; вместо этого он переводит поток в HTTP.

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

Из RFC-2616:

Объект, возвращенный с этим ответом, ДОЛЖЕН включать указание текущего состояния запроса и либо указатель на монитор состояния, либо некоторую оценку того, когда пользователь может ожидать, что запрос будет выполнен.

Я думаю, что ключевым моментом здесь является «сущность», поскольку вопрос заключается в том, включаем ли мы индикацию состояния в заголовках ответов или в теле ответа. Почти везде, на которое ссылается сущность, это, по-видимому, подразумевает тело ответа. Например:

10.5 Ошибка сервера 5xx

Коды состояния ответа, начинающиеся с цифры «5», указывают случаи, когда сервер знает, что он ошибался или не может выполнить запрос. За исключением случаев ответа на запрос HEAD, сервер ДОЛЖЕН включать объект, содержащий объяснение ситуации ошибки, и является ли это временным или постоянным условием. Пользовательские агенты ДОЛЖНЫ отображать любой объект, включенный в список . Эти коды ответов применимы к любому методу запроса.

Я не видел, чтобы браузер отображал заголовки ответов пользователю. И за 303-е годы:

10.3.4 303 См. Другие

Различное URI ДОЛЖНО указываться полем «Местоположение» в ответе. Если метод запроса не был HEAD, сущность ответа СЛЕДУЕТ содержать короткую гипертекстовую ноту с гиперссылкой на новый URI (ы).

Вы не получите гипертекстовый ответ в заголовках.

Однако в разделе 7 совершенно ясно, что означает объект:

Сущность состоит из полей заголовка объекта и тела объекта, хотя некоторые ответы будут включать только заголовки объектов.

Я думаю, что в вашем случае, что вы делаете, соответствует RFC-2616. Однако, реалистично это все сводится к реализации клиента. Может ли клиент, получающий ваш ответ 202, обрабатывать заголовок Location: для ответа 2xx ? Это должен быть ваш лакмусовый тест на то, как реагировать, а также тест, используемый для управления стандартами во время их стандартизации / документации.

Фактически, в соответствии с rfc 7240 http://tools.ietf.org/html/rfc7240#section-4.1 вы можете отправить код состояния 202 вместе с заголовком Location. Это было бы в асинхронном ответе, хотя, по-видимому, PHP не позволит вам это сделать.

RFC допускает неопределенность в отношении этой концепции. Это означает, что спецификация в настоящее время не говорит о том, как «Location» используется с 202, но, с другой стороны, это не лицензия для библиотек, которая просто заменяет код состояния. Так что это окончательно ошибка PHP.