У меня есть файл обработки, который обрабатывает отправленные пользователем данные, однако перед этим он сравнивает вводимые клиентом данные с ожидаемыми значениями, чтобы гарантировать отсутствие изменений данных на стороне клиента.
Могу сказать, что я не очень разбираюсь в кодах состояния 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 Bad Request. Однако из объяснений я понял, что ошибка возникает из-за несуществующего запроса, а не из-за недопустимых входных данных.
С другой стороны, 417 Expectation Failed, похоже, как раз подходит для моего случая, однако я никогда раньше не видел и не экспериментировал с этим статусом заголовка.
Мне нужен ваш опыт и мнение, большое спасибо!
Для получения полной информации о черновиках страниц форм/процессов и моих экспериментах, перейдите по ссылкеэта ссылка.
Дополнение: Еще одна причина, по которой я хочу этого, — это предотвращение манипуляций Google. Это будет использоваться не только в бэкэнде, но и во фронтэнде, где будет показано взаимодействие гостя и пользователя и представлено содержимое страницы.
Я считаю*, что присвоение кодов статуса 200 OK или 403 Forbidden допустимо для страниц, которые существуют или которым разрешено существовать.
*Дополнение два: я сейчас изучил 417 и 100 и обнаружил, что они похожи на то, что я пытаюсь сделать (по крайней мере, только в случае обработки загрузки), вот здесь: http://benramsey.com/blog/2008/04/http-status-100-continue/
- то есть:*Веб-страница, ссылающаяся на сайт X сhttp://www.example.com/page.php?query=lol&query2=failбудет проиндексирован Google, поскольку HTTP-заголовок имеет значение OK.
РЕШЕНИЕ, К КОТОРОМУ Я ПРИШЕЛ:
Действительно, 404 — это то, к чему я могу снова прийти. Я просто хотел другое решение, чем это, если HTTP его предоставляет, но пока что 404 кажется лучшим решением, пригодным для этого, спасибо всем, мой вопрос нашел свой ответ.
решение1
Если параметры запроса GET неверны, каноническим решением будет отправить ответ 404 (не найдено) или 200 (OK).
RESTful-способ использования GET-запросов заключается в запросе ресурса (получении чего-либо). Таким образом, если требуемые параметры не соответствуют существующему ресурсу (потому что они неполны), можно точно сказать, что ресурс, запрошенный в URI, не найден.
На практике, если вы хотите избежать таких вещей, как игнорирование браузерами вашей страницы 404 и подстановка своей собственной (я рассматриваю IE 9 и 10), вы можете использовать 200. Если вы считаете, что ресурсом является ваше приложение, то 200 подойдет; вы запросили приложение, и оно вернуло результат (который оказался ошибкой, но не на уровне HTTP). Однако такое использование не очень соответствует RESTful.
решение2
Ошибка 417должна возникать только тогда, когда клиент отправляет HTTP- Expectзаголовок, который сервер не может выполнить, что никак не связано с «ожидаемыми входными данными» приложения в запросе. Не используйте его.
С другой стороны, сообщение 400об ошибке должно отправляться только в том случае, если в HTTP-запросе присутствует неверный синтаксис, который сервер не понимает.
Ни один из этих вариантов не подходит для случая сбоя проверки в логике приложения, хотя, я полагаю, 400он немного более уместен.
Ошибка 403, которую вы рассматривали в своем вопросе на Stack Overflow, на мой взгляд, является наилучшим вариантом.
Я просто использовал заголовок 403 Forbidden, когда ожидаемые значения не были найдены в $_GET, но, если подумать, это на самом деле не действие, требующее входа в систему (не в этом случае, конечно, пользователь должен войти в систему, чтобы просмотреть панель администратора в первую очередь), это больше похоже на ввод неожиданного значения.
Вы имеете в виду 401, который является кодом ответа, используемым при необходимости аутентификации. 403— это общее отклонение запроса, что звучит как раз то, что вам нужно.
Все это предполагает, что вы хотите вернуть 4xxкод ответа, что имеет смысл для API, но для HTML-страницы, видимой пользователю, вы, скорее всего, захотите отправить сообщение 200с информацией об ошибке в теле.
решение3
Я не совсем понимаю, что вы делаете, однако есть дополнительная опция, которую вы, возможно, не учли - 200 - OK. Причина в том, что вы получили данные правильно, проблема в том, что они недействительны для вашего приложения, что на самом деле не является проблемой протокола HTTP.
Соответствующий документ RFC здесь:rfc2616. Вы можете использовать 400, но тогда вам нужно предоставить клиенту возможность изменять данные, из RFC
10.4.1 400 Неверный запрос
Запрос не может быть понят сервером из-за неправильного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений.
Относительно 417 в RFC говорится:
10.4.18 417 Ожидание не оправдалось
Ожидание, указанное в поле заголовка запроса Expect (см. раздел 14.20), не может быть выполнено данным сервером, или, если сервер является прокси-сервером, у сервера есть недвусмысленные доказательства того, что запрос не может быть выполнен сервером следующего перехода.
поэтому, если вы не используете заголовок expect, вам, вероятно, не следует использовать этот ответ.