Может ли веб-приложение возвращать 400 Bad Request при некорректных параметрах?
От: Geri Россия http://web-notes.ru/
Дата: 02.10.12 07:14
Оценка:
Довольно часто при разработке веб-приложений возникает необходимость выдать пользователю какой-то ответ, означающий, что пользователь не передал какой-то обязательный параметр или переданный параметр имеет недопустимое значение. При беглом просмотре списка кодов ошибок HTTP, кажется, что для этого наиболее подходит код 400 Bad Request. Однако, в описании к нему говорится, что этот код используется, когда запрос не может быть понят сервером из-за синтаксической ошибки в запросе. Например, какие-то недопустимые символы в URI, нет обязательного заголовка "Host" в запросе HTTP/1.1, и т.п. То есть все те ошибки, которые обрабатывает веб-сервер ещё до вызова скрипта-обработчика (например, PHP). Следовательно сам PHP-скрипт не должен выдавать код 400, т.к. если PHP-скрипт вызвался, значит запрос прошел формальную проверку на уровне веб-сервера и с синтаксисом у него всё в порядке.

Для ряда ситуаций нас вполне может спасти код 404 Not Found (даже когда речь идёт о query-параметре, т.к. query является частью URI). Но не всегда. Например, в POST-запросе не пришел параметр, который должен был придти, без которого запрос теряет всякий смысл -- посылать 404 в данном случае было бы неправильно, т.к. сам URL правильный. Обычно в таких случаях разработчики просто кидают какое-то общее исключение, которое потом где-то на уровне index.php или Front-контроллера перехватывается и трансформируется в ошибку 500 Internal Server Error. Иногда, вместо нее шлют 503 Service Unavailable, чтобы показать тем самым временность проблемы (если проблема связана с каким-то сбоем или ошибкой в коде), чтобы типа поисковики не удаляли сайт из индекса. На мой взгляд это неправильно, т.к. статус ошибки фактически не соответствует её сути.

Главная проблема в том, что 500-ые ошибки в такого рода ситуациях говорят клиенту о том, что проблема находится на стороне сервера, тогда как 400-ые ошибки говорят в основном о проблеме на стороне клиента. RFC-2616 говорит о том, что при получении клиентом 400-ой ошибки клиент НЕ ДОЛЖЕН повторять запрос без изменения запроса. И действительно, если запрос изначально некорректный, сколько его не повторяй -- результат не изменится. Тогда как при получении 500 ошибки клиент может продолжать "долбить" сервер снова и снова в то время как проблема -- в неправильном запросе. RFC-2616 очень скуп на описание данной ошибки и ограничивается всё тем же синтаксисом и приводом пары частных примеров. Однако, что такое ошибка синтаксиса? Можно ли считать отсутствующий или неправильный параметр, который требуется в каком-то частном обработчике, синтаксической ошибкой? Я раньше считал, что нет, хотя и были сомнения. Но недавно я обнаружил, что Facebook возвращает 400 Bad Request в случае если при авторизации через OAuth передан неправильный query-параметр с кодом, и об этом написано в официальной документации. То есть фэйсбук считает неправильный GET-параметр синтаксической ошибкой.

Кто-нибудь может дать пояснение по данной теме? Вопрос весьма не тривиальный, на большинстве форумов топик бы засрали прыщавые быдлокодеры, не дав ни одного ценного ответа. На RSDN вроде бы достаточно зрелая аудитория, поэтому вся надежда на неё. Меня интересует не личный опыт применения кода 400 Bad Request теми или иными программистами, я понимаю, что из скрипта можно послать любой код HTTP, а официальное подтверждение допустимости такого использования со ссылкой на какой-нибудь RFC или IETF.
-- С уважением, Павел Мелехов, Екатеринбург.
http 400 bad request rfc-2616
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.