HTTP 400 (bad request) для логической ошибки, а не искаженного синтаксиса запроса

на спецификация HTTP / 1.1 (RFC 2616) говорит о значении код состояния 400, неверный запрос (§10.4.1):

запрос не может быть понят сервер из-за неправильного синтаксиса. Клиент не должен повторять запрос без изменений.

кажется, что в наши дни существует общая практика среди нескольких API на основе HTTP использовать 400 для обозначения логическое а не а синтаксис ошибка с просьбой. Я предполагаю, что APIs делает это, чтобы различать 400 (клиент-индуцированной) и 500 (сервер-индуцированной). Неприемлемо или некорректно использовать 400 для обозначения не-синтаксические ошибки? Если это приемлемо, есть ли аннотированная ссылка на RFC 2616, которая обеспечивает более глубокое понимание предполагаемого использования 400?

примеры:

59
http http-status-code-400 http-status-codes

6 ответов

статус 422 (RFC 4918, раздел 11.2) приходит на ум:

код состояния 422 (необработанная сущность) означает, что сервер понимает тип содержимого сущности запроса (следовательно, код состояния 415(неподдерживаемый тип носителя) неуместен), и синтаксис сущности запроса правильный (таким образом, код состояния 400 (плохой запрос) неуместен), но не смог обработать содержащиеся инструкции. Например, эта ошибка может возникнуть, если XML тело запроса содержит хорошо сформированные (т. е. синтаксически правильные), но семантически ошибочные XML-инструкции.

59

на данный момент, последний проект HTTPbis спецификация, которая предназначена для замены и устаревания RFC 2616,государства:

код состояния 400 (неверный запрос) указывает, что сервер не может или не будет обрабатывать запрос, так как полученный синтаксис недопустим, бессмысленно, или превышает некоторые ограничения на то, что сервер готов обрабатывать.

Это определение, хотя конечно все равно при условии изменения, ратифицирует широко используемую практику реагирования на логические ошибки С 400.

13

HTTPbis будет адресовать фразировку 400 Bad Request, чтобы она также охватывала логические ошибки. Так что 400 будет включать 422.

от https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-7.4.1
"Сервер не может обработать запрос из-за ошибки клиента (например, неправильный синтаксис)"

6

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

только мои 2 цента ... Нам нужны адвокаты и судьи, чтобы интерпретировать язык в RFC в эти дни:)

Спасибо, Виш

2

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

например, если веб-служба Restful документирована как принимающая сообщения с пользовательским типом контента XML application/vnd.example.com.widget+xml, и вы вместо этого отправляете какой-то тарабарский простой текст или двоичный файл, кажется, resasonable рассматривать это как синтаксическую ошибку - ваше тело запроса не находится в ожидаемом форма.

Я не знаю никаких официальных ссылок на это, хотя, как обычно, это, похоже, сводится к интерпретации RFC 2616.

обновление: обратите внимание на изменение формулировки в RFC 7231 §6.5.1:

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

Кажется, поддерживает этот аргумент больше, чем сейчас устарел RFC 2616 §10.4.1, который сказал просто:

запрос не может быть понят сервером из-за синтаксических ошибок. Клиент не должен повторять запрос без изменений.

2

на серверах Java EE возвращается 400, если Ваш URL-адрес ссылается на несуществующее "веб-приложение". Это "синтаксическая ошибка"? Зависит от того, что вы подразумеваете под синтаксической ошибкой. Я бы сказал Да.

в английском языке правила синтаксиса предписывают определенные отношения между частями речи. Например," Боб женится на Мэри " синтаксически правильно, потому что он следует шаблону {существительное + глагол + существительное}. Поскольку "Bob marriage Mary" было бы синтаксически неверно, {существительное + существительное + Существительное.}

синтаксис простого URLis { protocol+: + / / + server +: + port }. Согласно этому"http://www.google.com:80" синтаксически правильно.

но как насчет " abc: / / www.Гугл.com: 80"? Похоже, все идет по той же схеме. Но на самом деле это синтаксическая ошибка. Почему? Потому что " abc " не является определенным протоколом.

дело в том, что определение того, есть ли у нас ситуация 400, требует больше, чем разбор символов и пробелы и разделители. Он должен также признать, что являются действительными "частями речи".

1