| Код статуса Http | Код состояния Значение |
|---|
| 100 | Клиент должен продолжать отправлять запросы. Этот временный ответ используется для информирования клиента о том, что часть его запроса была получена сервером и не была отклонена. Клиент должен продолжить отправку оставшейся части запроса или проигнорировать этот ответ, если запрос завершен. Сервер должен отправить клиенту окончательный ответ, когда запрос будет завершен. |
| 101 | Сервер понял запрос клиента и уведомит его через заголовок сообщения Upgrade о необходимости использовать другой протокол для завершения запроса. После отправки последней пустой строки этого ответа сервер переключится на протоколы, определенные в заголовке сообщения Upgrade. Это следует делать только в том случае, если переход на новый протокол более выгоден. Например, переход на новую версию HTTP выгоднее, чем на старую, или переход на протокол реального времени и синхронный протокол для доставки ресурсов, использующих такие возможности. |
| 102 | Коды состояния, расширенные WebDAV (RFC 2518), означают, что обработка будет продолжена. |
| 200 | Запрос выполнен успешно, и в этом ответе будет возвращен заголовок ответа или тело данных, требуемое запросом. |
| 201 | Запрос был выполнен, и новый ресурс был создан в соответствии с требованиями запроса, а его URI был возвращен с заголовком Location. Если требуемый ресурс не может быть создан вовремя, следует вернуть '202 Accepted'. |
| 202 | Сервер принял запрос, но еще не обработал его. Точно так же, как он может быть отклонен, в конечном итоге запрос может быть выполнен или не выполнен. В контексте асинхронных операций нет ничего более удобного, чем отправка этого кода состояния. Цель возвращения ответа с кодом состояния 202 - позволить серверу принимать запросы от других процессов (например, пакетных операций, выполняемых только раз в день) без необходимости держать клиента подключенным к серверу до полного завершения пакетной операции. Ответ, принимающий запрос на обработку и возвращающий код состояния 202, ДОЛЖЕН включать в возвращаемую сущность некоторую информацию, указывающую на текущее состояние процесса, а также указатель на монитор состояния обработки или предсказание состояния, чтобы пользователь мог оценить, завершилась ли операция. |
| 203 | Сервер успешно обработал запрос, но возвращаемая метаинформация заголовка сущности - это не окончательный набор, действующий на исходном сервере, а копия, полученная от локального или третьего лица. Текущая информация может быть подмножеством или надмножеством исходной версии. Например, метаданные, содержащие ресурсы, могут привести к тому, что оригинальный сервер будет знать супернабор метаинформации. Использование этого кода состояния не является обязательным и уместно только в том случае, если без него ответ вернул бы 200 OK. |
| 204 | Сервер успешно обработал запрос, но ему не нужно возвращать физическое содержимое и он хочет вернуть обновленную метаинформацию. Ответ может вернуть новую или обновленную метаинформацию в виде заголовков сущностей. Если такие заголовки существуют, они должны соответствовать запрошенным переменным. Если клиентом является браузер, то браузер пользователя ДОЛЖЕН сохранить страницу, на которую был отправлен запрос, без изменения вида документа, даже если согласно спецификации новая или обновленная метаинформация ДОЛЖНА быть применена к документу в активном представлении браузера пользователя. Поскольку ответ 204 не может содержать никакого тела сообщения, он всегда заканчивается первой пустой строкой после заголовка сообщения. |
| 205 | Сервер успешно обработал запрос и ничего не вернул. Однако, в отличие от ответа 204, ответ, возвращающий этот код состояния, просит запросчика сбросить представление документа. Этот ответ в основном используется для сброса формы сразу после приема пользовательского ввода, чтобы пользователь мог легко начать другой ввод. Как и ответ 204, этот ответ не содержит тела сообщения и заканчивается первой пустой строкой после заголовка сообщения. |
| 206 | Сервер успешно обработал часть GET-запроса. Такие инструменты загрузки HTTP, как FlashGet или Thunderbolt, используют этот тип ответа для выполнения прерывистой загрузки или для разбиения большого документа на несколько сегментов загрузки одновременно. Запрос должен содержать заголовок Range для указания диапазона содержимого, которое клиент хочет получить, и может содержать If-Range в качестве условия запроса. Ответ должен содержать следующие поля заголовка: Content-Range для указания диапазона содержимого, возвращаемого в этом ответе; в случае многосегментной загрузки с Content-Type multipart/byteranges, каждый многосегментный сегмент должен содержать поле Content-Range, указывающее на диапазон содержимого в этом сегменте. Если ответ содержит Content-Length, его значение должно соответствовать истинному количеству байт в возвращаемом диапазоне содержимого. date ETag и/или Content-Location, если тот же запрос должен был вернуть ответ 200. Expires, Cache-Control и/или Vary, если их значения могут отличаться от других ответов с теми же переменными. Expires, Cache-Control и/или Vary, если их значения могут отличаться от значений других предыдущих ответов с теми же переменными. Этот ответ НЕ ДОЛЖЕН содержать другие заголовки сущностей, если запрос использует сильную проверку кэша If-Range, и НЕ ДОЛЖЕН содержать другие заголовки сущностей, если запрос использует слабую проверку кэша If-Range; это позволяет избежать несоответствий между кэшированным содержимым сущности и обновленной информацией заголовка сущности. В противном случае, этот ответ ДОЛЖЕН содержать все поля заголовков сущностей, которые должны были быть возвращены во всех ответах 200, которые должны были быть возвращены. Если заголовки ETag или Last-Modified не совпадают в точности, кэш на стороне клиента ДОЛЖЕН запретить объединение содержимого, возвращенного в ответе 206, с любым ранее кэшированным содержимым. Любому кэшу, который не поддерживает заголовки Range и Content-Range, запрещено кэшировать содержимое, возвращаемое ответом 206. |
| 207 | Код состояния, расширенный WebDAV (RFC 2518), означает, что последующее тело сообщения будет XML-сообщением и может содержать ряд отдельных кодов ответа, в зависимости от количества предыдущих подзапросов. |
| 300 | Запрашиваемый ресурс имеет ряд альтернативных ответных сообщений, каждое из которых имеет свой собственный адрес и информацию о переговорах, определяемую браузером. Пользователь или браузер может самостоятельно выбрать предпочтительный адрес для перенаправления. Если это не запрос HEAD, ответ должен содержать сущность, представляющую собой список характеристик и адресов ресурсов, из которых пользователь или браузер может выбрать наиболее подходящий адрес перенаправления. Формат этой сущности определяется форматом определения Content-Type. Браузер может автоматически сделать наиболее подходящий выбор, основываясь на формате ответа и собственных возможностях браузера. Конечно, спецификация RFC 2616 не указывает, как должен осуществляться такой автоматический выбор. Если у сервера уже есть предпочтительный вариант ответа, то URI этого ответа должен быть указан в Location; браузер может использовать это значение Location в качестве адреса для автоматического перенаправления. Кроме того, этот ответ можно кэшировать, если не указано иное. |
| 301 | Запрашиваемый ресурс был навсегда перемещен в новое местоположение, и любые будущие ссылки на него должны использовать один из нескольких URI, возвращенных в этом ответе. Если возможно, клиенты с возможностью редактирования ссылок должны автоматически изменять запрашиваемый адрес на тот, который возвращается сервером. Этот ответ также можно кэшировать, если не указано иное. Новый постоянный URI должен быть возвращен в поле Location ответа. Если это не запрос HEAD, сущность ответа должна содержать гиперссылку на новый URI и краткое описание. Если это не запрос GET или HEAD, браузеру запрещается автоматически перенаправлять запрос, если он не подтвержден пользователем, так как в результате условия запроса могут измениться. Примечание: Для некоторых браузеров, использующих протокол HTTP/1.0, при отправке POST-запроса и получении ответа 301 следующий запрос на перенаправление будет GET. |
| 302 | Запрашиваемый ресурс теперь временно отвечает на запрос с другого URI. Поскольку это перенаправление является временным, клиент должен продолжать отправлять последующие запросы на исходный адрес. Этот ответ можно кэшировать, только если он указан в Cache-Control или Expires. Новый временный URI должен быть возвращен в поле Location ответа. Если это не запрос HEAD, сущность ответа должна содержать гиперссылку на новый URI и краткое описание. Если это не запрос GET или HEAD, то браузеру запрещено автоматически перенаправлять запрос, если он не подтвержден пользователем, так как в результате условия запроса могут измениться. Примечание: Хотя спецификации RFC 1945 и RFC 2068 не позволяют клиенту изменять метод запроса при перенаправлении, многие существующие браузеры рассматривают ответ 302 как ответ 303 и используют GET для доступа к URI, указанному в Location, игнорируя метод исходного запроса. Коды состояния 303 и 307 были добавлены, чтобы уточнить, какой ответ ожидает сервер от клиента. |
| 303 | Ответ на текущий запрос может быть найден на другом URI, и клиент должен получить доступ к этому ресурсу с помощью GET. Этот метод существует в первую очередь для того, чтобы активированный скриптом вывод POST-запроса можно было перенаправить на новый ресурс. Этот новый URI не является альтернативной ссылкой на исходный ресурс. Кроме того, ответ 303 запрещено кэшировать. Конечно, второй запрос (перенаправление) может быть кэширован. Новый URI должен быть возвращен в поле Location ответа. Если только это не запрос HEAD, сущность ответа должна содержать гиперссылку на новый URI и краткое описание. Примечание: Многие браузеры до версии HTTP/1.1 не понимают состояние 303 должным образом. Если необходимо взаимодействие с этими браузерами, то код состояния 302 должен быть достаточно эффективным, так как большинство браузеров обрабатывают ответ 302 точно так же, как вышеприведенная спецификация требует от клиента обрабатывать ответ 303. |
| 304 | Сервер ДОЛЖЕН возвращать этот код состояния, если клиент отправил условный GET-запрос, который был разрешен, и содержимое документа (либо с момента последнего посещения, либо в соответствии с условиями запроса) не изменилось.304 ответ не может содержать тела сообщений, и поэтому всегда заканчивается первой пустой строкой после заголовка сообщения. Ответ ДОЛЖЕН содержать следующие заголовки: Дата, если только на сервере нет часов. Если сервер без часов следует этим правилам, то прокси-сервер и клиент могут самостоятельно добавить поле Date в заголовок входящего ответа (как указано в RFC 2068), и механизм кэширования будет работать корректно.ETag и/или Content-Location, если тот же запрос вернул бы ответ 200.Expires Expires, Cache-Control и/или Vary, если значение может отличаться от значения, соответствующего другим предыдущим ответам для той же переменной. Если этот запрос использует сильную проверку кэша, то этот ответ не должен содержать другие заголовки сущности; в противном случае (например, условный запрос GET использует слабую проверку кэша), этому ответу запрещено содержать другие заголовки сущности; это позволяет избежать несоответствия между кэшированным содержимым сущности и обновленной информацией заголовка сущности. Если ответ 304 указывает на то, что сущность в настоящее время не кэшируется, система кэширования должна проигнорировать этот ответ и повторить запрос без ограничения. Если получен ответ 304 с запросом на обновление записи кэша, система кэширования ДОЛЖНА обновить всю запись, чтобы отразить значения всех полей, обновленных в ответе. |
| 305 | Запрашиваемый ресурс должен быть доступен через указанный прокси. поле Location содержит информацию о URI, на котором расположен указанный прокси. получателю необходимо повторно отправить отдельный запрос для доступа к ресурсу через этот прокси. Только оригинальный сервер может создать ответ 305. Примечание: Из RFC 2068 не ясно, что ответ 305 предназначен для перенаправления одного запроса и может быть создан только оригинальным сервером. Игнорирование этих ограничений может привести к серьезным последствиям для безопасности. |
| 306 | В последней версии спецификации код состояния 306 больше не используется. |
| 307 | Запрашиваемый ресурс теперь временно отвечает на запрос с другого URI. Поскольку такое перенаправление является временным, клиенты должны продолжать отправлять последующие запросы по исходному адресу. Этот ответ можно кэшировать, только если он указан в Cache-Control или Expires. Новый временный URI должен быть возвращен в поле Location ответа. Если только это не запрос HEAD, сущность ответа должна содержать гиперссылку на новый URI и краткое описание. Поскольку некоторые браузеры не распознают ответ 307, вышеуказанная информация должна быть добавлена, чтобы пользователь мог понять и запросить доступ к новому URI. Если это не запрос GET или HEAD, то браузер запрещает автоматическое перенаправление, если это не подтверждено пользователем, поскольку условия запроса могут измениться. |
| 400 | 1. произошла семантическая ошибка, и текущий запрос не может быть понят сервером. Если запрос не изменен, клиент не должен повторно отправлять его. 2. Неверные параметры запроса. |
| 401 | Текущий запрос требует аутентификации пользователя. Ответ должен содержать заголовок WWW-Authenticate для запрашиваемого ресурса, чтобы запросить информацию о пользователе. Клиент может повторно отправить запрос, содержащий соответствующую информацию заголовка Authorisation. Если текущий запрос уже содержит учетные данные авторизации, то ответ 401 означает, что сервер проверяет, что эти учетные данные были отклонены. Если ответ 401 содержит тот же запрос аутентификации, что и предыдущий ответ, и браузер уже пытался пройти аутентификацию хотя бы один раз, то браузер ДОЛЖЕН предоставить пользователю информацию о сущности, содержащуюся в ответе, поскольку эта информация о сущности может содержать соответствующую диагностическую информацию. См. RFC 2617. |
| 402 | Этот код статуса зарезервирован для возможных будущих требований. |
| 403 | Сервер понял запрос, но отказывается его выполнять. В отличие от ответа 401, аутентификация не предоставляет никакой помощи, и этот запрос не следует отправлять повторно. Если это не запрос HEAD и сервер хочет иметь возможность четко сказать, почему запрос не может быть выполнен, то причина отказа должна быть описана внутри сущности. Конечно, сервер может вернуть ответ 404, если он не хочет предоставлять клиенту никакой информации. |
| 404 | Запрос не выполнен, запрашиваемый ресурс не найден на сервере. Нет никакой информации, чтобы сообщить пользователю, является ли ситуация временной или постоянной. Если сервер знает о ситуации, он должен использовать код состояния 410, чтобы сообщить пользователю, что старый ресурс постоянно недоступен из-за какого-то внутреннего механизма конфигурации и что перенаправление недоступно. 404 широко используется, когда сервер не хочет раскрывать, почему запрос был отклонен, или когда нет другого подходящего ответа. |
| 405 | Метод запроса, указанный в строке запроса, не может быть использован для запроса соответствующего ресурса. В ответ должен быть возвращен заголовок Allow, указывающий на список методов запроса, допустимых для данного ресурса. Учитывая, что методы PUT и DELETE записывают ресурс на сервере, большинство веб-серверов не поддерживают эти методы запроса или не разрешают их по умолчанию и возвращают ошибку 405 для таких запросов. |
| 406 | Характеристики содержимого запрашиваемого ресурса не удовлетворяют условиям в заголовке запроса, и сущность ответа не может быть сгенерирована. Если только это не запрос HEAD, в ответ должна быть возвращена сущность, содержащая список характеристик и адресов сущностей, из которых пользователь или браузер может выбрать наиболее подходящую. Формат сущности определяется типом носителя, определенным в заголовке Content-Type. Браузеры могут сделать свой собственный выбор, основываясь на формате и собственных возможностях. Однако спецификация не определяет никаких критериев для такого автоматического выбора. |
| 407 | Аналогичен ответу 401, за исключением того, что клиент ДОЛЖЕН аутентифицироваться на прокси-сервере. Прокси-сервер ДОЛЖЕН вернуть Proxy-Authenticate для проверки подлинности. Клиент МОЖЕТ вернуть заголовок Proxy-Authorization для аутентификации. См. RFC 2617. |
| 408 | Таймаут запроса. Клиент не завершил отправку запроса в течение времени, которое сервер был готов ждать. Клиент может повторно отправить запрос в любое время, не внося никаких изменений. |
| 409 | Запрос не может быть завершен из-за конфликта с текущим состоянием запрашиваемого ресурса. Этот код разрешается использовать только в том случае, если пользователь считает себя способным разрешить конфликт и повторно отправить новый запрос. Ответ должен содержать достаточно информации, чтобы пользователь мог обнаружить источник конфликта. Конфликты обычно возникают при обработке запросов PUT. Например, в среде проверки версий, если информация о версии, приложенная к PUT-запросу на изменение определенного ресурса, конфликтует с предыдущим (сторонним) запросом, сервер должен вернуть ошибку 409, информирующую пользователя о том, что запрос не может быть выполнен. В этом случае ответная сущность, скорее всего, будет содержать сравнение различий между двумя конфликтующими версиями, чтобы пользователь мог повторно отправить новую версию после слияния. |
| 410 | Запрашиваемый ресурс больше не доступен на сервере и не имеет известного адреса пересылки. Такое состояние следует считать постоянным. Если возможно, клиенты с возможностью редактирования ссылок должны удалить все ссылки на этот адрес с разрешения пользователя. Если сервер не знает или не может определить, является ли это состояние постоянным, то следует использовать код состояния 404. Если не указано иное, этот ответ является кэшируемым.410 Цель этого ответа - помочь веб-мастеру в поддержке сайта, сообщив пользователю, что ресурс больше не доступен и что владелец сервера желает, чтобы все удаленные соединения с этим ресурсом также были удалены. Этот тип событий часто встречается в ограниченных по времени услугах с добавленной стоимостью. Аналогично, ответ 410 используется для уведомления клиентов о том, что ресурс, который изначально принадлежал какому-либо лицу на текущем сайте сервера, больше не доступен. Конечно, владелец сервера сам решает, нужно ли пометить все постоянно недоступные ресурсы как "410 Gone" и как долго эта пометка должна сохраняться. |
| 411 | Сервер отказывается принимать запросы без определенного заголовка Content-Length. После добавления корректного заголовка Content-Length, указывающего на длину тела сообщения запроса, клиент может отправить запрос снова. |
| 412 | Серверу не удалось удовлетворить одно или несколько предварительных условий при проверке того, что они были указаны в поле заголовка запроса. Этот код статуса позволяет клиенту задать предварительные условия в мета-сообщении запроса (данные поля заголовка запроса) при получении ресурса, тем самым предотвращая применение метода запроса к ресурсам, отличным от желаемого содержимого. |
| 413 | Сервер отказывается обрабатывать текущий запрос, поскольку в нем представлены данные о сущности, размер которых превышает размер, который сервер хочет или может обработать. В этом случае сервер может закрыть соединение, чтобы клиент не смог продолжить отправку этого запроса. Если это условие временное, сервер должен вернуть заголовок ответа Retry-After, чтобы сообщить клиенту, через какое время он может повторить запрос. |
| 414 | Длина URI запроса превышает длину, которую может интерпретировать сервер, поэтому сервер отказывается обслуживать запрос. Такое случается редко, чаще всего это происходит, когда при отправке формы, которая должна была использовать метод POST, используется метод GET, что приводит к длинной строке запроса. "Черные дыры" в URI перенаправления, например, использование старого URI как части нового URI при каждом перенаправлении, что приводит к длинному URI после нескольких перенаправлений. Клиенты пытаются атаковать серверы, используя уязвимости безопасности, существующие в некоторых серверах. Такие серверы используют буфер фиксированной длины для чтения или манипулирования URI запроса, и когда параметры после GET превышают определенное значение, может произойти переполнение буфера, что приведет к выполнению произвольного кода [1]. Серверы, не имеющие подобных уязвимостей, должны возвращать код состояния 414. |
| 415 | Для текущего запрошенного метода и запрашиваемого ресурса сущность, переданная в запросе, не имеет формата, поддерживаемого сервером, поэтому запрос отклоняется. |
| 416 | Если запрос содержит заголовок запроса Range, и любые диапазоны данных, указанные в Range, не пересекаются с диапазонами, доступными для текущего ресурса, а заголовок запроса If-Range не определен в запросе, то сервер должен вернуть код состояния 416. Если Range использует байтовые диапазоны, то это происходит в том случае, если первая позиция байта всех диапазонов данных, указанных в запросе, превышает длину текущего ресурса. Сервер также должен включить заголовок сущности Content-Range, в котором указывается длина текущего ресурса вместе с кодом состояния 416. Этому ответу также запрещено использовать multipart/byteranges в качестве Content-Type. |
| 417 | Ожидаемое содержимое, указанное в заголовке запроса Expect, не может быть выполнено сервером, или этот сервер является прокси-сервером, который имеет четкие доказательства того, что содержимое Expect не может быть выполнено на следующем узле в текущем маршруте. |
| 421 | Количество соединений с сервером с IP-адреса, на котором находится текущий клиент, превышает максимально допустимое для сервера. Как правило, под IP-адресом здесь понимается адрес клиента, видимый с сервера (например, адрес шлюза или прокси-сервера пользователя). В этом случае количество соединений может включать более одного конечного пользователя. |
| 422 | Количество подключений к серверу с IP-адреса текущего клиента превышает максимально допустимое сервером. Как правило, под IP-адресом здесь понимается адрес клиента, видимый с сервера (например, адрес шлюза или прокси-сервера пользователя). В этом случае количество соединений может включать более одного конечного пользователя. |
| 422 | Запрос был отформатирован правильно, но на него нельзя было ответить, так как он содержал семантические ошибки. (RFC 4918 WebDAV) 423 Заблокирован Текущий ресурс заблокирован. (RFC 4918 WebDAV) |
| 424 | Текущий запрос завершился неудачей из-за ошибки, произошедшей в предыдущем запросе, например PROPPATCH.(RFC 4918 WebDAV) |
| 425 | Определена в проекте WebDav Advanced Collections, но отсутствует в протоколе WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Клиентам следует перейти на TLS/1.0.(RFC 2817) |
| 449 | Расширено компанией Microsoft для обозначения того, что запросы должны быть повторно запрошены после выполнения соответствующего действия. |
| 500 | Сервер столкнулся с непредвиденными условиями, которые не позволили ему завершить обработку запроса. Как правило, такая проблема возникает при наличии ошибки в программном коде сервера. |
| 501 | Сервер не поддерживает определенную функцию, необходимую для выполнения текущего запроса. Когда сервер не может распознать запрашиваемый метод и не в состоянии поддержать запрос на какой-либо ресурс. |
| 502 | Сервер, работающий в качестве шлюза или прокси, получает недопустимый ответ от вышестоящего сервера при попытке выполнить запрос. |
| 503 | В настоящее время сервер не может обработать запрос из-за временного обслуживания или перегрузки. Это состояние является временным и будет восстановлено через некоторое время. Если ожидается задержка, ответ может содержать заголовок Retry-After, указывающий на задержку. Если информация о Retry-After не предоставлена, то клиент должен обработать его так же, как и ответ 500. Примечание: Существование кода состояния 503 не означает, что сервер должен использовать его, если он перегружен. Некоторые серверы просто хотят отказать клиенту в соединении. |
| 504 | Сервер, работающий в качестве шлюза или прокси, который пытается выполнить запрос, не получает своевременного ответа от вышестоящего сервера (сервера, идентифицируемого по URI, например HTTP, FTP, LDAP) или вторичного сервера (например, DNS). Примечание: Некоторые прокси-серверы возвращают ошибку 400 или 500, когда поиск DNS завершается. |
| 505 | Сервер не поддерживает или отказывается поддерживать версию HTTP, используемую в запросе. Это означает, что сервер не может или не хочет использовать ту же версию, что и клиент. Ответ должен содержать сущность, описывающую, почему версия не поддерживается и какие протоколы поддерживает сервер. |
| 506 | Расширено протоколом Transparent Content Negotiation Protocol (RFC 2295) для представления внутренней неправильной конфигурации сервера: запрашиваемый ресурс Negotiation Variant настроен на использование себя в прозрачных переговорах по содержимому, и поэтому не является подходящим фокусом в процессе переговоров. |
| 507 | Сервер не может хранить содержимое, необходимое для выполнения запроса. Это состояние считается временным.WebDAV (RFC 4918) |
| 509 | Сервер достиг предела пропускной способности. Это не официальный код состояния, но все еще широко используется. |
| 510 | Политика, необходимая для получения ресурса, не была нарушена. (RFC 2774) |