422 unprocessable entity что это
Коды ошибок HTTP: полный список ошибок сервера
Умные люди придумали коды, по которым можно определить, что произошло с HTTP-запросом. Успешен ли он, произошло ли перенаправление. Или же все закончилось ошибкой. Как раз об ошибках и будем говорить в этой статье. Вкратце расскажу, какие они бывают и с чем связаны.
А еще тут будет парочка забавных (и не очень) пикч и анимаций на тему описанных ошибок. Хоть какое-то развлечение.
Ошибки со стороны клиента (4xx)
Для начала перечислим коды ошибок на стороне клиента. Вина за их появление ложится на плечи обоих участников соединения.
400 Bad Request
Такой ответ от браузера можно получить в том случае, если сервер не смог правильно отреагировать на запрос со стороны пользователя. Часто код 400 возникает при попытке клиента получить доступ к серверу без соблюдения правил оформления синтаксиса протокола передачи гипертекста (HTTP). Повторный запрос не стоит отправлять до тех пор, пока не будет исправлена ошибка (или несколько из них).
401 Unauthorized
Код 401 возникает при попытке клиента получить доступ к серверу, используя неправильные данные для авторизации. По сути, используется, когда пользователь вводит неправильный логин и пароль на ресурсе, где требуется эта информация для входа. Читайте: Как исправить ошибку 401
402 Payment Required
Эта ошибка сообщает клиенту о том, что для успешного выполнения запроса ему необходимо оплатить доступ к серверу. Изначально код 402 должен был стать неким стандартом для цифровой валюты и оплаты контента в сети. Но не срослось. До сих пор нет единого решения по поводу того, как должны выглядеть платежи в сети. Также нет и единого решения по поводу того, как стоит использовать 402.
Все еще считается, что код существует с расчетом на будущее. Сейчас почти не используется и поддерживается не всеми браузерами.
403 Forbidden
Почти то же, что и 401. Сервер снова не разрешает к нему подключиться, хотя с запросом все в порядке. Просто нет доступа. Причем повторная авторизация с другими логином и паролем никак не помогут. Все вопросы к владельцам сервера (но не всегда). Инструкция по устранению ошибки.
Творчество на тему знаменитой киносаги
404 Not Found
Легендарная ошибка, ставшая популярным мемом. 404 оповещает клиента о том, что его запрос ведет в никуда. Код возникает, когда пользователь пытается попасть на страницу, которой не существует. Например, когда случайно ошибается при вводе ссылки и вводит ее с опечаткой. Или же пытается получить доступ к странице, которой на сайте уже нет.
В отличие от других кодов, страницу с 404 частенько кастомизируют, создавая для нее уникальный дизайн. Мало того, что это выглядит симпатичнее, так еще и полезнее для посетителей. Можно прямо на странице с ошибкой разъяснить, что произошло и как дальше действовать.
И таких вариаций тысячи. Каждый пытается добавить в оформление что-то свое.
405 Method Not Allowed
405 сообщает клиенту о том, что метод, используемый при запросе, не разрешен. В качестве примера можно привести попытку со стороны клиента ввести данные в форму с помощью GET, когда она работает только с POST. Ну и в таком же духе.
406 Not Acceptable
Ошибка 406 сообщает о том, что страница передает контент, который не может быть распознан клиентом. Возможно, проблема в методе сжатия или в формате страницы. Иногда сюда же приплетают неправильные настройки кодировки.
Этот код редко используют на практике, так как его появления можно избежать, предоставив пользователю информацию на сайте в том виде, который его браузер способен принять. Посетитель сайта по итогу получит не то, что ожидал, но хотя бы не ошибку.
407 Proxy Authentication Required
Этот код тоже похож на 401. Только на этот раз логин и пароль нужны не для основного сервера, а для прокси, который находится между клиентом и сервером. Обычно в теле ошибки содержится информация о том, как можно правильно пройти авторизацию и получить доступ к ресурсу.
408 Request Timeout
408 говорит нам о том, что сервер пожелал разорвать соединение с клиентом, потому что оно никак не используется. Происходит это в том случае, если сервер буквально устал ждать, пока наладится соединение с ним. Поэтому такую ошибку часто можно лицезреть после очень долгой и безуспешной загрузки какого-нибудь сайта.
Многие серверы не отправляют никаких сообщений, а просто прерывают соединение по той же причине. На запрос уходит больше времени, чем на то полагается.
В Мистере Роботе частенько называли серии в честь ошибок HTTP (весь четвертый сезон в нумерации 4хх). В честь 408, например, назвали восьмую серию четвертого сезона
409 Conflict
Сообщение о конфликте возникает, когда запрос со стороны клиента не соответствует тому, чего ожидает сервер. В качестве примера приводят проблемы при проверки версий, когда пользователь пытается с помощью метода PUT загрузить на сервер новый файл, но там уже имеется более новая версия того же файла. Конфликта версий можно легко избежать, загрузив корректную версию.
410 Gone
Своего рода аналог 404. Разница лишь в том, что 410 намекает на перманентность отсутствия страницы. Так что этот код стоит использовать, когда на 100% уверен, что страница ушла в небытие (ну или с текущего адреса) навсегда. В любом другом случае есть универсальный 404.
411 Length Required
411 оповещает пользователя о том, что сервер не желает принимать запрос со стороны клиента, потому что в нем не определен заголовок Content-Length. Да, это первый код в подборке, который смогут понять только люди, сведущие в настройке серверов. По-простому уложить сущность HTML-заголовков в этот материал не получится.
412 Precondition Failed
Еще один код, сообщающий о том, что сервер отклонил запрос пользователя и не разрешает доступ к выбранному ресурсу. Проблемы возникают при неправильной настройке работы методов, отличающихся от GET и HEAD.
413 Payload Too Large/Request Entity Too Large
Код 413 говорит нам, что запрос, который посылает клиент на сервер, слишком большой. Поэтому сервер отказывается его обрабатывать и разрывает соединение. Обычно это происходит при попытке загрузить на ресурс какой-то файл, превышающий ограничение, выставленное в настройках сервера. Соответственно, решается проблема изменением настроек сервера.
414 URI Too Long
Чем-то этот код похож на предыдущий. Здесь тоже идет речь о превышение лимита. Только теперь это касается не запроса со стороны клиента, а длины URI. То есть ссылки. Выходит, что адрес, используемый клиентом, больше, чем тот, что может обработать сервер. Как-то так.
Такая ошибка иногда выскакивает при попытке взломать ресурс. Сайт так реагирует на слишком частые попытки воспользоваться потенциальными дырами в безопасности.
415 Unsupported Media Type
Ошибка 415 возникает, когда клиент пытается загрузить на сервер данные в неподходящем формате. В таком случае сервер просто отказывается принимать посылаемые файлы и разрывает соединение. Как и в случае с 413.
416 Range Not Satisfiable
Подобный ответ можно ожидать, если клиент запрашивает у сервера определенные данные, но эти данные на сервере не соответствуют запросу. То есть, грубо говоря, вы просите у сервера какой-то набор данных с заранее заданным размером, а в итоге оказывается, что размер этих данных меньше, чем объем, указанный в запросе. Серверу ничего не остается, кроме как послать вас, ведь он не обучен поведению в таких ситуациях.
417 Expectation Failed
Такая ошибка высвечивается, когда ожидания сервера не совпадают с данными в запросе клиента. Сведения об ожиданиях прописываются в заголовке Expect заранее. Так что можно ознакомиться с ними, чтобы выяснить, как решить названную проблему.
418 I’m a teapot
Код 418 можно увидеть, если сервер откажется варить кофе, потому что он чайник. Это первоапрельская шутка. Естественно, 418 не используется нигде всерьез и просто существует как дань памяти программистам-юмористам, придумавшим это в 1998 году.
У Google получился такой симпатичный чайник
421 Misdirected Request
Появляется когда запрос клиента переправляется на сервер, который не может дать на него адекватный ответ. Например, если запрос был отправлен на ресурс, который вообще не настроен обрабатывать запросы извне.
Чтобы исправить проблему, можно попробовать переподключиться к ресурсу заново или попробовать другое соединение.
422 Unprocessable Entity
Код 422 говорит, что сервер вроде бы принял запрос, понял его, все хорошо, но из-за семантических ошибок корректно обработать не смог. Значит, где-то в запросе затаилась логическая ошибка, мешающая корректному взаимодействию клиента и сервера. Надо ее найти и исправить.
423 Locked
Обычно на этот код напарываются, когда запрашиваемый ресурс оказывается под защитой. Используемые клиентом методы блокируются на уровне сервера. Это делается, чтобы обезопасить данные, хранящиеся на защищенной странице. Без логина и пароля выудить информацию с такого сервера не получится.
424 Failed Dependency
424 сообщает о том, что для выполнения запроса со стороны клиента успешно должна завершиться еще одна или несколько параллельных операций. Если какая-то из них «провалится», то «помрет» все соединение сразу, и обработать запрос до конца не получится. Аналогичное происходит, если некорректно был обработан один из предыдущих запросов.
425 Too Early
Появляется в ответ на запрос, который может быть моментально запущен заново. Сервер не рискует и не берется за его обработку, чтобы не подставиться под так называемую «атаку повторного воспроизведения».
426 Upgrade Required
Тут нам прямо сообщают, что сервер не желает с нами общаться, пока мы не перейдем на более современный протокол. Наткнуться на такую ошибку очень тяжело, но в случае появления, скорее всего, будет достаточно установить браузер посвежее.
428 Precondition Required
428 выскакивает, если пользователь отправляет запрос на сервер, но получает некорректные или неактуальные данные. Так ресурс оповещает о необходимости внести в запрос информацию о предварительных условиях обработки данных. Только так он сможет гарантировать получение клиентом нужной информации.
429 Too Many Requests
Здесь все просто. Ошибка появляется, когда клиент отправляет на сервер слишком много запросов в короткий промежуток времени. Очень похоже на поведение взломщиков. По этой причине запрос моментально блокируется.
431 Request Header Fields Too Large
Из названия понятно, что ошибка с кодом 431 появляется из-за того, что в запросе клиента используются слишком длинные заголовки (неважно, один или несколько из них). Исправляется это с помощью сокращения заголовков и повторной отправки запроса. В теле ошибки обычно отображается краткая информация о том, как пользователь может решить эту проблему самостоятельно.
444 No Response
Этот код вам вряд ли удастся увидеть. Он отображается в лог-файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение.
449 Retry With
Код используется в расширениях компании Microsoft. Он сигнализирует о том, что запрос от клиента не может быть принят сервером. Причиной становятся неверно указанные параметры. Сама 449 ошибка говорит о необходимости скорректировать запрос и повторить его снова, подготовив к работе с сервером.
450 Blocked by Windows Parental Controls
450 код увидят дети, попавшие под действие системы «Родительский контроль» компании Microsoft. По сути, ошибка говорит о том, что с компьютера попытались зайти на заблокированный ресурс. Избежать этой ошибки можно изменением параметров родительского контроля.
451 Unavailable For Legal Reasons
Этот код сообщает клиенту, что он не может попасть на запрашиваемый ресурс из юридических соображений. Скорее всего, доступ был заблокирован из-за каких-нибудь государственных санкций, нового законодательства или цензуры со стороны властей. В общем, все вопросы к государству и провайдеру связи.
Ошибка 422: Суть проблемы и пути решения
Код состояния 422 (HTTP 422 Unprocessable Entity) обозначает ошибку со стороны пользователя, а не API. Сервер понимает запрос со стороны клиента и может работать с типом содержимого, который ему предоставили. Однако логическая ошибка делает выполнение невозможным.
Самые частые причины возникновения ошибки 422:
Проблема ошибка 422 через Ajax Post с использованием Laravel
В ajax этот код может выдаваться как ошибка по умолчанию, когда проверка не выполняется. Либо возвращаться Laravel при запросе, в котором допущена опечатка. Можно попробовать сделать запрос в консоли браузера: он должен выдать JSON с ошибками, возникшими во время проверки запроса. Есть вероятность, что код просто отправляет атрибуты формы не так, как вы запланировали. В любом случае, проблему решать программисту или вебмастеру.
Дополнительная информация
В первую очередь, попробуйте просмотреть свои данные и сделать запрос по вызывающему сомнения участку кода. Нужно убедиться, что вы правильно определили фрагмент данных, в котором содержится причина ошибки.
Если вы все еще не можете найти, где закралась ошибка 422 или вышеописанные способы не помогли выявить описанных причин сбоя функционирования, попробуйте спросить совет у общества веб-разработчиков, показав пример фрагмента вашего кода, чтобы узнать, могут ли другие определить, в чем проблема.
400 против 422 ответа на POST данных
Я пытаюсь выяснить, какой правильный код состояния должен возвращаться в различных сценариях с помощью API-интерфейса типа REST, над которым я работаю. Допустим, у меня есть конечная точка, которая позволяет делать покупки POST в формате JSON. Это выглядит так:
Что я должен вернуть, если клиент отправляет мне «sales_tax» (вместо ожидаемого «налога»). В настоящее время я возвращаю 400. Но я начал сомневаться в этом. Должен ли я действительно возвращать 422? Я имею в виду, что это JSON (который поддерживается) и это действительный JSON, он просто не содержит всех обязательных полей.
400 Bad Request теперь может показаться лучшим кодом состояния HTTP / 1.1 для вашего варианта использования.
Во время вашего вопроса (и моего первоначального ответа) RFC 7231 не был чем-то особенным; в этот момент я возразил, 400 Bad Request потому что RFC 2616 сказал (с акцентом мой):
и запрос, который вы описываете, является синтаксически допустимым JSON, заключенным в синтаксически допустимый HTTP, и, следовательно, у сервера нет проблем с синтаксисом запроса.
Код состояния 400 (неверный запрос) указывает на то, что сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, синтаксис искаженного запроса, кадрирование неверного сообщения запроса или обманчивая маршрутизация запроса).
Однако до этой переписки (или если вы хотите поспорить о том, что RFC 7231 является только предлагаемым стандартом прямо сейчас), 422 Unprocessable Entity не кажется неправильным код состояния HTTP для вашего варианта использования, потому что во введении к RFC 4918 говорится:
Хотя коды состояния, предоставляемые HTTP / 1.1, достаточны для описания большинства состояний ошибок, с которыми сталкиваются методы WebDAV, есть некоторые ошибки, которые не попадают аккуратно в существующие категории. Эта спецификация определяет дополнительные коды состояния, разработанные для методов WebDAV (Раздел 11)
Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type) является неподходящим), и синтаксис объекта запроса является правильным (таким образом, 400 (неверный запрос) ) код состояния не подходит), но не удалось обработать содержащиеся в нем инструкции.
(Обратите внимание на ссылку на синтаксис; я подозреваю, что 7231 частично устарел и 4918)
Это звучит точно так же, как ваша ситуация, но на случай, если возникли какие-либо сомнения, он говорит:
Например, это условие ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (то есть синтаксически правильные), но семантически ошибочные инструкции XML.
(Замените «XML» на «JSON», и я думаю, что мы можем согласиться, что это ваша ситуация)
Теперь некоторые будут возражать, что RFC 4918 относится к «HTTP-расширениям для Web-распределенной авторизации и управления версиями (WebDAV)» и что вы (предположительно) ничего не делаете с WebDAV, поэтому не должны использовать его.
Учитывая выбор между использованием кода ошибки в исходном стандарте, который явно не охватывает ситуацию, и кодом из расширения, которое точно описывает ситуацию, я бы выбрал последний.
Я предполагаю, что для клиента или сервера HTTP вполне разумно использовать любой код состояния из этого реестра, если они делают это правильно.
Сервер не может понять запрос из-за неправильного синтаксиса. Клиент НЕ ДОЛЖЕН повторять запрос без изменений.
Это условие ошибки может возникнуть, если тело XML-запроса содержит правильно сформированные (т. Е. Синтаксически правильные), но семантически ошибочные инструкции XML.
Чтобы сохранить единый интерфейс, вы должны использовать 422 только в случае ответов XML, а также поддерживать все коды состояния, определенные расширением Webdav, а не только 422.
Смотрите также сообщение Марка Ноттингема о кодах статуса:
Чтобы отразить статус на 2015 год:
Поведенческие и ответные коды 400 и 422 будут одинаково восприниматься клиентами и посредниками, так что это на самом деле не имеет конкретного значения, которое вы используете.
Однако я ожидаю увидеть 400 используемых в настоящее время более широко, и, кроме того, пояснения, которые предоставляет спецификация HTTPbis, делают его более подходящим из двух кодов состояния:
Пример использования GitHub API
Существует три возможных типа ошибок клиента при вызовах API, которые получают тела запросов:
Отправка неверного JSON приведет к ответу 400 Bad Request.
Отправка неправильного типа значений JSON приведет к ответу 400 Bad Request.
Отправка неверных полей приведет к ответу 422 Unprocessable Entity.
Правильного ответа нет, поскольку это зависит от того, какое определение «синтаксис» используется для вашего запроса. Самое главное, что вы:
Прежде чем все обрушатся на меня, сказав, что здесь нет правильного или неправильного ответа, позвольте мне немного объяснить, как я пришел к выводу.
В этом конкретном примере вопрос OP касается запроса JSON, который содержит ключ, отличный от ожидаемого. Теперь полученное имя ключа очень похоже, с точки зрения естественного языка, на ожидаемый ключ, но оно строго отличается и, следовательно, не распознается (обычно) машиной как эквивалентное.
Объяснение 422 необработанного объекта Обновлено: 6 марта 2017 г.
Что такое 422 необработанный объект?
Код состояния 422 возникает, когда запрос правильно сформирован, однако из-за семантических ошибок он не может быть обработан. Этот статус HTTP был введен в RFC 4918 и более конкретно ориентирован на расширения HTTP для Web Distributed Authoring and Versioning (WebDAV).
Существует некоторое противоречие относительно того, должны ли разработчики возвращать клиентам ошибку 400 против 422 (подробнее о различиях между обоими статусами ниже). Однако в большинстве случаев считается, что статус 422 следует возвращать только в том случае, если вы поддерживаете возможности WebDAV.
Дословное определение кода состояния 422, взятого из раздела 11.2 в RFC 4918, можно прочитать ниже.
Код состояния 422 (Unprocessable Entity) означает, что сервер понимает тип содержимого объекта запроса (следовательно, код состояния 415 (Unsupported Media Type) является неподходящим), и синтаксис объекта запроса является правильным (таким образом, 400 (неверный запрос) ) код состояния не подходит), но не удалось обработать содержащиеся в нем инструкции.
Определение продолжает говорить:
Например, это условие ошибки может возникнуть, если тело запроса XML содержит правильно сформированные (то есть синтаксически правильные), но семантически ошибочные инструкции XML.
400 против 422 кодов состояния
Ошибочные ошибки запроса используют код состояния 400 и должны быть возвращены клиенту, если синтаксис запроса неверен, содержит недопустимое обрамление сообщения запроса или имеет обманчивую маршрутизацию запроса. Этот код состояния может показаться очень похожим на состояние необработанного объекта 422, однако одна небольшая часть информации, которая их отличает, заключается в том, что синтаксис объекта запроса для ошибки 422 является правильным, тогда как синтаксис запроса, который генерирует 400 ошибка неверна
Использование статуса 422 должно быть зарезервировано только для очень конкретных случаев использования. В большинстве других случаев, когда произошла ошибка клиента из-за неправильного синтаксиса, следует использовать статус 400 Bad Request.
Идеальный сценарий для 422:
В идеальном мире 422 является предпочтительным и в целом приемлемым для отправки в качестве ответа, если сервер понимает тип содержимого объекта запроса, и синтаксис объекта запроса является правильным, но не смог обработать данные, поскольку они семантически ошибочны.
Ситуации 400 на 422:
В корпоративной архитектуре сервисы развертываются в основном на сервисных уровнях, таких как SOA, IDM и т. Д. Они обычно обслуживают несколько клиентов, начиная от очень старого собственного клиента и заканчивая новейшими клиентами HTTP. Если один из клиентов не обрабатывает HTTP 422, возможны варианты, когда клиент просит обновить или изменить код ответа на HTTP 400 для всех. По моему опыту, это очень редко в наши дни, но все еще возможность. Поэтому перед принятием решения о кодах ответа HTTP всегда требуется тщательное изучение вашей архитектуры.
Чтобы справиться с подобной ситуацией, сервисные уровни обычно используют versioning или устанавливают configuration флаг для клиентов строгого соответствия HTTP для отправки 400 и отправки 422 для остальных из них. Таким образом, они обеспечивают поддержку обратной совместимости для существующих потребителей, но в то же время предоставляют возможность новым клиентам использовать HTTP 422.
Последнее обновление RFC7321 гласит:
Во-первых, это очень хороший вопрос.
например, заголовок авторизации или заголовок типа контента. Который абсолютно необходим серверу для понимания запроса. Это может отличаться от сервера к серверу.
Это менее серьезно, чем 400. Запрос достиг сервера. Сервер подтвердил, что запрос имеет правильную базовую структуру. Но информация в теле запроса не может быть проанализирована или понята.
Вот статья, в которой перечислены коды состояния и их использование в REST API. https://metamug.com/article/status-codes-for-rest-api.php
На самом деле вы должны вернуть «200 OK» и в теле ответа включить сообщение о том, что произошло с опубликованными данными. Тогда ваше приложение должно понять сообщение.
Позвольте мне привести не виртуальный пример. Допустим, вы влюбились в девушку, и она любит вас обратно, но ее семья переезжает в совершенно другую страну. Она дает вам свой новый почтовый адрес. Естественно, вы решили отправить ей любовное письмо. Итак, вы пишете свое письмо, кладете его в конверт, пишете ее адрес на конверте, ставите на нем штамп и отправляете его. Теперь давайте рассмотрим эти сценарии
Короче говоря, возвращение «200 OK» не означает, что у серверного приложения есть хорошие новости для вас. Это только означает, что у него есть новости.
PS: код состояния 422 имеет значение только в контексте WebDAV. Если вы не работаете с WebDAV, то 422 имеет то же самое стандартное значение, что и любой другой нестандартный код = которого нет.