У меня есть файл обработки, который обрабатывает данные, отправленные пользователем, однако до этого он сравнивает ввод от клиента с ожидаемыми значениями, чтобы гарантировать отсутствие изменений данных на стороне клиента.
Я могу сказать, что не очень разбираюсь в кодах состояния HTTP, но я провел некоторое исследование по этому поводу и решил выбрать, какой из них лучше всего подходит для неожиданной обработки ввода. Итак, я придумал:
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
Теперь я не могу точно сказать, какой из них использовать, я видел, как много используется 400 неверных запросов, однако из объяснения я понял, что ошибка связана с несуществующим запросом, а не с незаконным вводом.
С другой стороны, 417 Expectation Failed кажется мне подходящим вариантом, однако я никогда раньше не видел и не экспериментировал с этим статусом заголовка.
Мне нужен ваш опыт и мнение, большое спасибо!
Чтобы получить полную информацию о черновиках страниц форм / процессов и моих экспериментах, следуйте эта ссылка.
Дополнение: еще одна причина, почему я хочу этого, - предотвратить манипуляции со стороны Google. Это будет использоваться не только в бэкэнде, но и во фронтенде, где будет отображаться взаимодействие гостя / пользователя и будет представлено содержимое страницы.
Я считаю, что *, коды состояния 200 OK или 403 Forbidden действительны для страниц, которые существуют или разрешены к существованию.
* Дополнение второе: я изучил 417 и 100 сейчас и обнаружил, что они похожи на то, что я пытаюсь сделать (по крайней мере, для случая обработки загрузки), здесь: http://benramsey.com/blog/2008/04/http-status-100-continue/
РЕШЕНИЕ Я ПРИШЕЛ:
На самом деле 404 - это то, что я могу снова получить. Я просто хотел другое решение, если бы его предоставил HTTP, но до сих пор кажется, что 404 по-прежнему является лучшим решением, которое можно использовать для этого, спасибо всем, мой вопрос нашел ответ.
В 417 ошибка должна возникать только тогда, когда клиент отправил HTTP Expect заголовок, который сервер не может выполнить, который никак не связан с «ожидаемыми входами» приложения в запросе. Не используйте это.
С другой стороны, 400 сообщение об ошибке следует отправлять только в том случае, если в HTTP-запросе неверный синтаксис, который сервер не понимает.
Ни один из них не подходит для сбоя проверки в логике приложения, хотя я полагаю 400 немного более уместно.
В 403 ошибка, которую вы собирались использовать в своем вопросе на Stack Overflow, на мой взгляд, лучший вариант.
Я просто использовал заголовок 403 Forbidden, когда ожидаемые значения не были найдены в $ _GET, но, если подумать, на самом деле это не действие, требующее входа в систему (не для этого, конечно, пользователь должен войти в систему для просмотра администратора панель в первую очередь), это больше похоже на ввод неожиданного значения.
Ты думаешь о 401, который представляет собой код ответа, который используется при необходимости аутентификации. 403 это общий отказ в запросе, который звучит именно так, как вы хотите.
Все это предполагает, что вы хотите вернуть 4xx код ответа ... который имеет смысл для API ... но для пользовательской HTML-страницы вы, скорее всего, захотите отправить 200 с информацией об ошибке в теле.
Если параметры для запроса GET неверны, канонически нужно отправить обратно либо 404 (не найдено), либо 200 (ОК).
RESTful способ использования запросов GET - запросить ресурс (получить что-то). Следовательно, если требуемые параметры не соответствуют существующему ресурсу (потому что они неполные), вы можете точно сказать, что ресурс, запрошенный в URI, не найден.
На практике, если вы хотите избежать таких вещей, как браузеры, игнорирующие вашу страницу 404 и заменяющие их собственной (я смотрю на IE 9 и 10), вы можете использовать 200. Если вы считаете свое приложение ресурсом, 200 подходит; вы запросили приложение, и оно вернуло результат (это была ошибка, но не на уровне HTTP). Однако это использование не очень RESTful.
Я не могу понять, что вы делаете, но есть дополнительная опция, которую вы, возможно, не рассматривали - 200 - ОК. Причина в том, что вы правильно получили данные, проблема в том, что они недопустимы для вашего приложения, что на самом деле не является проблемой с протоколом HTTP.
Соответствующий RFC здесь rfc2616. Вы можете использовать 400, но тогда вам нужно предоставить клиенту возможность изменять данные из rfc
10.4.1 400 неверный запрос
Запрос не может быть понят сервером из-за неправильного синтаксиса. Клиенту НЕ СЛЕДУЕТ повторять запрос без изменений.
Что касается 417, RFC говорит
10.4.18 417 Неудачное ожидание
Ожидание, указанное в поле заголовка запроса Expect (см. Раздел 14.20), не может быть выполнено этим сервером, или, если сервер является прокси, сервер имеет недвусмысленное свидетельство того, что запрос не может быть выполнен сервером следующего перехода. .
поэтому, если вы не используете ожидаемый заголовок, вам, вероятно, не следует использовать этот ответ.