Является ли простая опечатка пароля действительно ошибкой HTTP?

Очевидно, что запросы POST некоторых форм должны приводить к ошибке HTTP 4xx (например, неправильный URL-адрес, отсутствие ожидаемого поля, невозможность отправки файла cookie аутентификации), но существующие вопросы подобно этому, кажется, предполагает, что все недопустимые отправки форм следует рассматривать как ошибки HTTP 4xx . Действительно?

Ошибки при вводе пароля или случайное пропуск обязательных полей — чрезвычайно распространенное и предполагаемое явление в приложении. Из какой-либо спецификации не ясно, что это должно представлять собой «ошибку клиента HTTP» или что POST можно считать успешным 2xx только в том случае, если он приводит к постоянному изменению состояния.

Я предполагаю, что моя интуиция такова, что если сервер отправляет клиенту форму, а клиент быстро отвечает правильно сформированным POST-запросом к этой форме со всеми ожидаемыми полями, обычное нарушение бизнес-логики не должно быть ошибкой HTTP.

Ситуация еще менее определена, если форма отправляется через что-то вроде JSON-RPC. HTTP — это всего лишь транспортный механизм, и если функция успешно вызвана и ответ возвращен вызывающему объекту, не должно быть ошибки HTTP.

Реже некоторые формы могут выполнять несколько действий, и одна часть может быть успешной, а другая - нет.

В идеале IETF мог бы устранить это с помощью RFC, возможно, добавив код ошибки HTTP для «операция не была выполнена из-за сбоя аннулирования формы» или расширив определение 422.


person Steve Clay    schedule 20.05.2016    source источник
comment
Зачем ты это опубликовал? Напишите блог.   -  person Amit    schedule 21.05.2016
comment
Вы задаете вопрос или пытаетесь ответить на связанный?   -  person Rocket Hazmat    schedule 21.05.2016
comment
Я думаю, что это был отдельный вопрос, но позвольте мне взглянуть еще раз.   -  person Steve Clay    schedule 21.05.2016
comment
Я перечитал то, что вы написали, и, возможно, оговорился, извините.   -  person Rocket Hazmat    schedule 21.05.2016
comment
Кажется, это аргумент против принятого ответа на сообщение, которое я упомянул, поэтому я должен ответить stackoverflow.com/questions/15580969/.   -  person Steve Clay    schedule 21.05.2016


Ответы (1)


Здесь нет правильного или неправильного. Я думаю, что HTML-формы в определенной степени противостоят дизайну HTTP.

Браузер здесь является HTTP-клиентом. Если он отправляет запрос и получает ошибку HTTP, он будет отображать тело ответа, но мало что сделает с кодом ответа.

С точки зрения HTTP, возможно, браузер не должен был «обновляться» до ошибки. Возможно, он должен был просто сообщить пользователю об ошибке и позволить ему изменить форму и повторить запрос.

С точки зрения HTML, самое разумное, что можно сделать, это вообще не отправлять сообщение об ошибке, а перенаправить обратно на URL-адрес формы, обычно с набором параметров запроса.

В случае JSON-RPC (и многих протоколов, таких как XML-RPC, Soap, а также более новых, таких как GraphQL) вообще не используется HTTP таким образом, чтобы он хорошо сочетался с HTTP.

В этом смысле они не являются HTTP-приложениями, они в значительной степени используют HTTP как «туннель». Они используют HTTP в качестве транспорта, но не «используют протокол HTTP» как таковой.

В этих ситуациях я не думаю, что уместно http выдавать коды ошибок. Ошибки обрабатываются на более высоком уровне, и вы, вероятно, всегда хотите использовать POST и возвращать 200 при передаче информации об ошибке в теле ответа.

Итак, вернемся к вашему вопросу:

  • Да, с точки зрения HTTP неверная отправка формы должна быть ошибкой 4xx. Неверный пароль 401.
  • Нет, это не самая разумная вещь в каждом реальном случае использования, например, в браузерах и протоколах, которые используют HTTP просто как транспорт.
  • Но если вы разрабатываете архитектуру на основе REST или хотите использовать HTTP по назначению, вам нужно сделать следующее.

Должны ли браузеры вести себя по-другому при обнаружении ошибки 422? Может быть. Но «произошла ошибка» обычно недостаточно для хорошего UX. Помимо изменения того, как браузеры ведут себя с ошибкой 422, вам может понадобиться медиа-тип с более конкретной информацией о том, как браузер должен сообщать клиенту о проблемах.

person Evert    schedule 20.05.2016
comment
Действительно полезно, но вы можете отправить его на stackoverflow.com/questions/15580969/, так как я думаю, что это будет закрыто. - person Steve Clay; 21.05.2016
comment
Если это было полезно для вас, я счастлив. К черту SO и их драконовскую бюрократию вокруг того, что является подходящим вопросом. - person Evert; 21.05.2016