204 код ответа сервера
Коды статусов ответа по протоколу HTTP
Информационный (Informational 1xx)
100=»Continue»
Начальная часть запроса принята, и клиент может продолжать передачу запроса.
101=»Switching Protocols»
Сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade.
Запрос клиента успешен (Successful 2xx)
Ответы в диапазоне 200-299 означают, что запрос клиента обработан успешно.
200=»OK»
Запрос клиента обработан успешно, и ответ сервера содержит затребованные данные.
201=»Created»
Этот код состояния используется в случае создания нового URI. Вместе с этим кодом результата сервер выдает заголовок Location (см. главу 19), который содержит информацию о том, куда были помещены новые данные.
202=»Accepted»
Запрос принят, но обрабатывается не сразу. В теле содержимого ответа сервера может быть дана дополнительная информация о данной транзакции. Гарантии того, что сервер в конечном итоге удовлетворит запрос, нет, даже несмотря на то, что на момент приема запрос выглядел допустимым.
203=»Non-Authoritative Information»
Информация в заголовке содержимого взята из локальной копии или у третьей стороны, а не с исходного сервера.
204=»No Content»
Ответ содержит код состояния и заголовок, но тело содержимого отсутствует. При получении этого ответа броузер не должен обновлять свой документ. Обработчик чувствительных областей изображений может возвращать этот код, когда пользователь щелкает на бесполезных или пустых участках изображения.
205=»Reset Content»
Броузер должен очистить форму, используемую в данной транзакции, для дополнительных входных данных. Полезен для CGI-приложений, требующих ввода данных.
Сервер возвращает лишь часть данных затребованного объема. Используется в ответе на запрос с указанием заголовка Range. Сервер должен указать диапазон, включенный в ответ, в заголовке Content-Range.
Запрос клиента переадресован (Redirection 3xx)
Код ответа в диапазоне 300-399 означает, что запрос не выполнен и клиенту нужно предпринять некоторые действия для удовлетворения запроса.
Это код ответа на заголовок lf-Modified-Since, если URI не изменялся с указанной даты. Тело содержимого не посылается, и клиент должен использовать свою локальную копию.
Доступ к затребованному URI должен осуществляться через proxy-сервер, указанный в заголовке Location.
Запрос клиента является неполным (Client Error 4xx)
Коды ответов в диапазоне 400-499 означают, что запрос клиента неполный. Эти коды могут также означать, что от клиента требуется дополнительная информация.
Сервер не будет обрабатывать запрос, потому что его тело имеет неподдерживаемый формат.
416=»Requested Range Not Satisfiable»
Запрашиваемый диапазон не допустим
Ожидание не удалось
Превышен лимит запросов
450=Rating Service Unavailable
451=Unavailable For Legal Reasons
452 could be site not permitted by employer,
453 could be site not permitted by ISP
460 Blocked by Repressive Regime
Ошибки сервера (Server Error 5xx)
Коды ответов в диапазоне 500-599 показывают, что сервер столкнулся с ошибкой и, вероятно, не сможет выполнить запрос клиента.
Сервер не поддерживает версию протокола HTTP, использованную в запросе.
Ошибки ( Error 7xx)
Ошибки ( Error 9xx)
Для отправки кода статуса из PHP используется директива «header Status».
Коды ответа HTTP
Код ответа (состояния) HTTP показывает, был ли успешно выполнен определённый HTTP запрос. Коды сгруппированы в 5 классов:
Если вы получили код ответа (состояния), которого нет в данном списке, в таком случае он является не стандартизированным кодом ответа (состояния), вероятней всего он кастомный сервера.
Следующая таблица содержит список всех кодов и их значения:
Этот ответ отсылается, когда веб сервер после выполнения server-driven content negotiation, не нашёл контента, отвечающего критериям, полученным из user agent.
Этот ответ отсылается, когда запрос конфликтует с текущим состоянием сервера.
Этот ответ отсылается, когда запрашиваемый контент удалён с сервера.
Размер запроса превышает лимит, объявленный сервером. Сервер может закрыть соединение, вернув заголовок Retry-After
Коды ответов REST API
REST API использует строку состояния в HTTP ответе (статус ответа), чтобы информировать Клиентов о результате запроса.
HTTP определяет 40 стандартных кодов состояния (статусов ответа), которые делятся на пять категорий. Ниже выделены только те коды состояния, которые используются в REST API.
| Категория | Описание |
|---|---|
| 2xx: Успех | Этот класс кодов состояния указывает, что запрос клиента был успешно получен, понят, и принят. |
| 3xx: Перенаправление | Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. |
| 4xx: Ошибка клиента | Класс кодов 4xx предназначен для указания ошибок со стороны клиента. |
| 5xx: Ошибка сервера | Коды ответов, начинающиеся с «5» указывают на случаи, когда сервер знает, что произошла ошибка или он не может обработать запрос. |
Коды состояний в REST
200 (OK)
Запрос выполнен успешно. Информация, возвращаемая с ответом зависит от метода, используемого в запросе, например при:
REST API отвечает кодом состояния 201 при каждом создании ресурса в коллекции. Также могут быть случаи, когда новый ресурс создается в результате какого-либо действия контроллера, и в этом случае 201 также будет подходящем ответом.
Ссылка (URL) на новый ресурс может быть в теле ответа или в поле заголовка ответа Location.
Сервер должен создать ресурс перед тем как вернуть 201 статус. Если это невозможно сделать сразу, тогда сервер должен ответить кодом 202 (Accepted).
Ответ 202 обычно используется для действий, которые занимают много времени для обработки и не могут быть выполнены сразу. Это означает, что запрос принят к обработке, но обработка не завершена.
Его цель состоит в том, чтобы позволить серверу принять запрос на какой-либо другой процесс (возможно, пакетный процесс, который выполняется только один раз в день), не требуя, чтобы соединение агента пользователя с сервером сохранялось до тех пор, пока процесс не будет завершен.
Сущность, возвращаемая с этим ответом, должна содержать указание на текущее состояние запроса и указатель на монитор состояния (расположение очереди заданий) или некоторую оценку того, когда пользователь может ожидать выполнения запроса.
Код состояния 204 обычно отправляется в ответ на запрос PUT, POST или DELETE, когда REST API отказывается отправлять обратно любое сообщение о состоянии проделанной работы.
API может также отправить 204 статус в ответ на GET запрос, чтобы указать, что запрошенный ресурс существует, но не имеет данных для добавления их в тело ответа.
Ответ 204 не должен содержать тело сообщения и, таким образом, всегда завершается первой пустой строкой после полей заголовка.
Вы вряд ли будете использовать этот код ответа в своем API, так как вы всегда можете использовать версию API для нового API, сохраняя при этом старый.
Является распространенным способом выполнить перенаправление на другой URL. HTTP-ответ с этим кодом должен дополнительно предоставит URL-адрес куда перенаправлять в поле заголовка Location. Агенту пользователя (например, браузеру) предлагается в ответе с этим кодом сделать второй запрос на новый URL.
Многие браузеры реализовали этот код таким образом, что нарушили стандарт. Они начали изменять Тип исходного запроса, например с POST на GET. Коды состояния 303 и 307 были добавлены для серверов, которые хотят однозначно определить, какая реакция ожидается от клиента.
Ответ 303 указывает, что ресурс контроллера завершил свою работу, но вместо отправки нежелательного тела ответа он отправляет клиенту URI ресурса. Это может быть URI временного сообщения о состоянии ресурса или URI для уже существующего постоянного ресурса.
Ответ 303 не должен кэшироваться, но ответ на второй (перенаправленный) запрос может быть кэшируемым.
В таком случае нет необходимости повторно передавать ресурс, так как у клиента все еще есть ранее загруженная копия.
Все это экономит ресурсы клиента и сервера, так как только заголовки должны быть отправлены и приняты, и серверу нет необходимости генерировать контент снова, а клиенту его получать.
Rest API может использовать этот код состояния для назначения временного URL запрашиваемому ресурсу.
Если метод запроса не HEAD, тело ответа должно содержать короткую заметку с гиперссылкой на новый URL. Если код 307 был получен в ответ на запрос, отличный от GET или HEAD, Клиент не должен автоматически перенаправлять запрос, если он не может быть подтвержден Клиентом, так как это может изменить условия, при которых был создан запрос.
Это общий статус ошибки на стороне Клиента. Используется, когда никакой другой код ошибки 4xx не уместен. Ошибки могут быть как неправильный синтаксис запроса, неверные параметры запроса, запросы вводящие в заблуждение или маршрутизатор и т.д.
Клиент не должен повторять точно такой же запрос.
Клиент может повторить запрос указав в заголовке подходящее поле авторизации. Если это уже было сделано, то в ответе 401 будет указано, что авторизация для указанных учетных данных не работает. Если в ответе 401 содержится та же проблема, что и в предыдущем ответе, и Клиент уже предпринял хотя бы одну попытку проверки подлинности, то пользователю Клиента следует представить данные полученные в ответе, владельцу сайта, так как они могут помочь в диагностике проблемы.
Ошибка 403 указывает, что rest API отказывается выполнять запрос клиента, т.е. Клиент не имеет необходимых разрешений для доступа. Ответ 403 не является случаем, когда нужна авторизация (для ошибки авторизации используется код 401).
Попытка аутентификация не поможет, и повторные запросы не имеют смысла.
Указывает, что rest API не может сопоставить URL клиента с ресурсом, но этот URL может быть доступен в будущем. Последующие запросы клиента допустимы.
API выдает ошибку 405, когда клиент пытался использовать HTTP метод, который недопустим для ресурса. Например, указан метод PUT, но такого метода у ресурса нет.
В таких случаях Клиент должен решить проблему данных у себя и только потом отправлять запросы повторно.
Когда клиент указывает rest API выполнять запрос только при выполнении определенных условий, а API не может выполнить запрос при таких условиях, то возвращается ответ 412.
Ошибка 500 никогда не является клиента, и поэтому для клиента разумно повторить точно такой же запрос, который инициировал этот ответ, и надеяться что в этот раз сервер отработает без ошибок.
Сервер не распознает метод запроса и не имеет возможности исполнить просьбу клиента. Обычно это подразумевает будущую доступность (например, новая функция API веб-сервиса).
HTTP протокол: основные правила Интернета, которые должен знать каждый веб-разработчик. Как браузер взаимодействует с сервером.
Успешные коды состояния HTTP сервера: 200, 201, 202, 203, 204, 205, 206
Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. В этой записи мы с тобой рассмотрим успешные коды состояния HTTP сервера, которые, как ты понимаешь, начинаются с двойки. Для начала мы посмотрим на список успешных кодов состояния и дадим и короткое пояснение, а затем мы посмотрим на то, как успешные коды состояния связаны с методами HTTP запроса. В конце этой публикации мы более подробно поговорим про каждый из успешных кодов состояния.
Успешные коды состояния HTTP сервера: 200, 201, 202, 203, 204, 205, 206
Общее описание успешных кодов состояния HTTP сервера
Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Успешные коды состояния HTTP сервера говорят клиенту о том, что его запрос успешно получен, понят, принят и обработан. Успешные коды состояния HTTP сервера всегда начинаются с двойки, давайте сведем в одну таблицу все успешные HTTP коды, как мы это делали для информационных кодов.
| Успешный код состояния | Описание успешного кода состояния HTTP севера |
| 200 OK | Успешный код состояния HTTP сервера 200: хорошо Код состояния 200 говорит клиенту о том, что его запрос удачно выполнен. |
| 201 Created | Успешный код состояния HTTP сервера 201: создан Код состояния 201 сообщает нам о том, что новый ресурс был создан успешно. |
| 202 Accepted | Успешный код состояния HTTP сервера 202: принято Код состояния 202 сообщает клиенту о том, что HTTP запрос успешно принят на обработку, но обработка еще не завершена, в этом случае сервер может отказать в обслуживание запроса клиента. |
| 203 Non-authoritative Information | Успешный код состояния HTTP сервера 203: не авторская информация Код состояния 203, отправленный в HTTP ответе, сообщает клиенту о том, что возвращенная в заголовке HTTP объекта информация – это не оригинал, который есть на первоначальном сервере, а документ, собранный из локальных копий или копий третьей стороны. |
| 204 No Content | Успешный код состояния HTTP сервера 204: нет содержимого Код состояния 204 говорит клиенту о том, что в ответном HTTP сообщении нет тела (про тело объекта HTTP). |
| 205 Reset Content | Успешный код состояния HTTP сервера 205: сбросить содержимое Если браузер получит код состояния 205, то он должен очистить форму, чтобы дать пользователю ввести дополнительные данные. |
| 206 Partial Content | Успешный код состояния HTTP сервера 206: частичное содержимое Код состояния 206 говорит браузеру о том, что HTTP сервер выполнил частичный GET запрос клиента (про методы HTTP). Чтобы получить такой код запрос клиента должен содержать поле заголовка Range, который указывает диапазон (вспоминаем диапазоны значений и HTTP параметры). |
Перейдем к рассмотрению HTTP кодов состояний из класса 2хх (если ты еще не знаешь про классы состояния HTTP)
HTTP код состояния 200 (успешно). HTTP код состояния 201 (создано). HTTP код состояния 202 (принято)
HTTP код состояния 200 сообщает о том, что запрос клиента был успешно принят и обработан. Информация, которая будет возвращена пользователю зависит от метода HTTP запроса. Давайте составим небольшую таблицу с методами и тем, какое содержимое им вернет сервер с HTTP кодом состояния 200.
| Метод HTTP запроса | Содержимое HTTP ответа с кодом 200 |
| GET | В ответ на метод GET клиент получит HTTP сообщение с кодом 200 и объект, который расположен по указанному URI в запросе (URI в HTTP). |
| POST | Если клиент отправляет запрос методом POST, то в ответ он получает сообщение с кодом состояния 200 с описание объекта или результатом действия метода POST. |
| TRACE | Клиент, отправивший запрос методом TRACE, получит HTTP ответ с кодом состояния 200, который будет содержать сообщение, полученное конечным сервером. |
| HEAD | В ответ на метод HEAD клиент получит сообщение с кодом состояния 200, в котором не будет тела сообщения |
HTTP код 200 мы рассмотрели, давайте перейдем к коду 201.
HTTP код состояния 201 сообщает клиенту о том, что запрос успешно выполнен и в результате этого запроса появился новый ресурс по указанному в запросе URI. Но сервер вместо кода 201 может послать код 202 в том случае, если он не может выполнить запрос клиента немедленно. Давайте перейдем к рассмотрению HTTP кода состояния 202.
HTTP код состояния 202 сообщает клиенту о том, что его запрос успешно принят на обработку, но обработка сервером еще не завершена. В итоге сервер может выполнить запрос клиента, а может его отклонить. Ответы с кодом состояния 202 уклончивы и это сделано преднамеренно, например, для того, чтобы дать серверу выполнить какой-то более важный запрос, а потом ответить клиенту, которому он отправлял HTTP сообщение с кодом состояния 202.
HTTP код состояния 203 (не авторская информация). HTTP код состояния 204 (нет содержимого). HTTP код состояния 205 (сбросить содержимое). HTTP код состояния 206 (частичное содержимое)
Перейдем к следующему успешному коду состояния HTTP сервера – код состояния 203, который говорит клиенту о том, что информация не авторская. HTTP код состояния 203 возвращает в заголовке своего сообщения информацию о том, что данное сообщение не является оригиналом, который доступен на первоначальном сервере и, возможно, информация взята из кэша HTTP сервера.
HTTP код состояния 204 говорит клиенту о том, что сервер успешно выполнил запрос, но никакой новой полезной информации нет. HTTP код состояния 204 используется чаще всего для работы с HTML формами для ввода пользовательских данных. Ответ с кодом состояния 204 не должен содержать тела сообщения.
HTTP код состояния 205 говорит браузеру о том, что ему следует (читай требования HTTP) отменить просмотр документа. Такой код состояния HTTP сервера чаще всего используется для очистки форм с целью повторного или последующего ввода и не содержит HTTP объекта.
HTTP код состояния 206 говорит о том, что был выполнен частичный метод GET. Чтобы получить такой код состояния запрос клиента должен содержать поле заголовка Range, в котором указывается диапазон в байтах, при этом ответ HTTP сервера должен содержать поле заголовка Content-Range, либо поле заголовка Content-Type.
Мы рассмотрели успешные коды состояния HTTP, давайте перейдем к кодам перенаправления. Еще есть коды ошибок клиента и коды ошибок сервера, о которых можно узнать на моём сайте. А если тебе нужна информацию обо всех кодах состояния, обратись к справочнику HTTP кодов состояния, в котором есть полное описание всех кодов.
Удобный справочник кодов состояния соединения.
Код состояния HTTP — это часть первой строки ответа сервера при запросах по протоколу.
Содержание.
100.
Информационные
100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки.
101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.
102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.
105 Name Not Resolved — возникла ошибка в связи с неверным или отсутствующем IP-адресом DNS-сервера.
Успешные
200 OK — успешный запрос. Клиенту отправлены запрошенные данные.
201 Created — в результате успешного выполнения запроса был создан новый ресурс. Если ресурс не может быть создан в данный момент, то сервер вместо этого должен отобразить код 202.
202 Accepted — запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как процесс может занять много времени.
203 Non-Authoritative Information — аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника, а из резервной копии, с другого сервера и т.д… Поэтому инфа может быть неактуальной.
204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.
Используется для того, чтобы позволить осуществить ввод или какие-либо действия без необходимости обновлять документ (страницу).
205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные, при этом тело сообщения не передаётся, поэтому страницу обновлять не обязательно.
Используется когда пользователь заполняет форму, а сервер посылает браузеру запрос на очистку формы.
206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого.
207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus.
226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.
Перенаправление
300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список вариантов, давая клиенту сделать выбор.
Такое происходит, когда пользователь использует URL на директорию не самого последнего уровня, и сервер предлагает ему выбор имеющихся файлов или директорий последующего уровня.
301 Moved Permanently — запрошенный документ был перенесен на новый URI адрес которого указанный в поле Location.
Некоторые клиенты некорректно ведут себя при обработке данного кода.
302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location.
Изначально представлял собой основной способ создания временного перенаправления. Тем не менее, сегодня существуют и другие – этичные, и неэтичные – способы его применения.
303 See Other — код указывает пользователю на то, что запрашиваемый ресурс можно найти по URL, который отличается от указанного в запросе. Это не обязательно означает, что что-то было перемещено, этот код лишь предоставляет адрес, по которому следует запрашивать подобный ответ.
Этот метод главным образом существует для того, чтобы позволить выводу данных POST-активированного скрипта перенаправить агента пользователя к выбранному ресурсу.
304 Not Modified — сервер возвращает такой код, если документ не изменился с момента последнего посещения сервера клиентом.
В этом коде сообщается о том, что параметры документа If-Modified-Since или If-Match не менялись с момента создания последнего кэша, и нет необходимости в повторной отправке ресурса.
305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси).
306 — использовался раньше, в настоящий момент зарезервирован.
307 Temporary Redirect — запрашиваемый ресурс, на короткое время, доступен по другому URI указанному в поле Location. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности.
Ошибки клиента
400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку.
401 Unauthorized — для доступа к запрашиваемому ресурсу требуется аутентификация.
Ответ сервера должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в сообщение требуемые для аутентификации данные.
402 Payment Required — предполагается использовать в будущем, сейчас не используется.
Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг.
404 Not Found — самая распространенная ошибка в интернете, основная причина — ошибка в написании адреса Web-страницы.
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI.
405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу.
В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented).
406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.
407 Proxy Authentication Required — ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.
408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT.
409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.
410 Gone — сервер посылает такой код если ресурс раньше был по указанному URL, но был удалён и теперь недоступен.
Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии. Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.
411 Length Required — сервер сообщает, что клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём.
412 Precondition Failed — возвращается, если ни одно из полей запроса не было выполнено.
Иными словами, один или более заголовок запроса был возвращен с атрибутом false.
413 Request Entity Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса.
Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.
414 Request-URL Too Long — сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.
415 Unsupported Media Type — сервер заметил, что часть запроса была сделана в неподдерживаемом формате.
В запросе не указываются какие-либо типы медиа, которые поддерживаются ресурсом или сервером. Например, пользователь запрашивает изображение с расширением файла, которое не поддерживается сервером.
416 Requested Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка.
417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса
418 I’m a teapot — код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol.
Не ожидается, что данный код будет поддерживаться реальными серверами.
422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом.
423 Locked — целевой ресурс заблокирован от применения к нему указанного метода.
424 Failed Dependency — указывает на то, что реализация текущего запроса может зависеть от успешности выполнения другой операции, и если она не будет успешно проведена, то вся обработка запроса будет прервана.
425 Unordered Collection — используется в расширении WebDAV Advanced Collections Protocol. Посылается, если клиент указал номер элемента в неупорядоченном списке, или запросил несколько элементов в порядке, отличающемся от серверного.
426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
428 Precondition Required — сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.
429 Too Many Requests — клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.
431 Request Header Fields Too Large — превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.
434 Requested host unavailable — запрашиваемый адрес недоступен.
444 — возвращается только сервером nginx. Бывают случаи, когда вы можете распознать по неким признакам бота, сканер или хакера. В таких случаях хорошо бы просто закрывать соединение. Вот для таких случаев и создан ответ 444. Собственно NGINX просто посылает в ответ пустой пакет (без заголовков) TCP RST и закрывает соединение.
449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.
451 Unavailable For Legal Reasons — доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту».
456 Unrecoverable Error — возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных. Введено корпорацией Microsoft для WebDAV.
499 — используется Nginx, когда клиент закрывает соединение до получения ответа.
Ошибка сервера
500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса.
501 Not Implemented — сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405.
502 Bad Gateway — сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера.
503 Service Unavailable — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.
504 Gateway Timeout — сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса.
505 HTTP Version Not Supported — сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.
506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается.
507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
509 Bandwidth Limit Exceeded — используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
510 Not Extended — на сервере отсутствует расширение, которое запрашивает клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником, например сервером провайдера — если клиент должен сначала авторизоваться в сети. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.