Чаевые: Ctrl F Быстрый поиск| Код состояния 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 или Thunder, используют этот тип ответа для достижения непрерывной передачи точки останова или разбивания большого документа на несколько сегментов загрузки для одновременной загрузки. Запрос должен содержать информацию заголовка Range, указывающую диапазон контента, который клиент хочет получить, и может содержать If-Range в качестве условия запроса. Ответ должен содержать следующие заголовки доменов: Content-Range используется для указания диапазона контента, возвращаемого в этом ответе; если это многосегментная загрузка Content-Type для multipart/byteranges, то каждый сегмент multipart должен содержать домен Content-Range для указания объема контента этого сегмента. Если ответ содержит Content-Length, его значение должно соответствовать реальному количеству байтов диапазона контента, который он возвращает. Date ETag и/или Content-Location, если тот же запрос должен был вернуть ответ 200. 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 не определяет, как следует осуществлять такой автоматический выбор. Если у самого сервера уже есть предпочтительный вариант обратной связи, в Location следует указать URI обратной связи; браузер может использовать это значение Location в качестве адреса для автоматического перенаправления. Кроме того, этот ответ также может быть кэширован, если не указано дополнительно. |
| 301 | Запрашиваемый ресурс был permanently перенесён на новое место, и в будущем все ссылки на этот ресурс должны использовать один из 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, если этот сервер не имеет часов. Если сервер без часов также соблюдает эти правила, прокси-сервер и клиент могут самостоятельно добавить поле Date в полученный заголовок ответа (как указано в RFC 2068), и механизм кэширования будет работать нормально. ETag и/или Content-Location, если тот же запрос должен был вернуть ответ 200. 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, применимый к запрошенному ресурсу, для запроса учётных данных пользователя. Клиент может повторно отправить запрос, содержащий корректный заголовок Authorization. Если текущий запрос уже содержит заголовок Authorization, то ответ с кодом 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 Locked текущий ресурс заблокирован. (RFC 4918 WebDAV) |
| 424 | Текущий запрос завершился неудачей из-за ошибки, возникшей при выполнении предыдущего запроса, например, при обработке PROPPATCH. (РФК 4918 WebDAV) |
| 425 | Определен в проекте WebDav Advanced Collections, но не в протоколе последовательности WebDAV (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-сервера). Внимание: некоторые прокси-серверы при превышении времени ожидания DNS-запросов возвращают ошибки 400 или 500. |
| 505 | Сервер не поддерживает или отклоняет версию HTTP, использованную в запросе. Это означает, что сервер не может или не хочет использовать ту же версию протокола, что и клиент. Ответ должен содержать сущность, описывающую, почему данная версия протокола не поддерживается, а также перечень протоколов, которые поддерживает сервер. |
| 506 | Расширенный Соглашением о прозрачном согласовании контента (RFC 2295), он представляет собой внутреннюю ошибку конфигурации сервера: запрашиваемый ресурс переменного элемента согласования настроен на использование себя в прозрачном согласовании контента, поэтому он не является подходящим направлением в процессе согласования. |
| 507 | Сервер не может сохранить содержимое, необходимое для выполнения запроса. Эта ситуация считается временной. WebDAV (RFC 4918) |
| 509 | Сервер достигает предела пропускной способности. Это не официальный код статуса, но он все еще широко используется. |
| 510 | Стратегии, необходимые для получения ресурсов, не были выполнены. (RFC 2774) |
Дружеские ссылки:iCMS