| Код статуса HTTP | Значение кода состояния |
|---|
| 100 | Клиент должен продолжать отправлять запросы. Этот предварительный ответ используется для информирования клиента о том, что часть его запроса получена сервером и еще не отклонена. Клиент ДОЛЖЕН продолжать отправлять оставшуюся часть запроса или игнорировать этот ответ, если запрос уже завершен. Сервер должен отправить окончательный ответ клиенту после завершения запроса. |
| 101 | Сервер понял запрос клиента и уведомит клиента через заголовок сообщения об обновлении, чтобы он использовал другой протокол для завершения запроса. После отправки последней пустой строки этого ответа сервер переключится на протоколы, определенные в заголовке 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, каждая составная часть должна содержать 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 не определяет, как должен выполняться такой автоматический выбор. Если у самого сервера уже есть предпочтительный вариант обратной связи, URI этой обратной связи должен быть указан в Location; браузер может использовать это значение Location в качестве адреса для автоматического перенаправления. Кроме того, этот ответ кэшируется, если не указано иное. |
| 301 | Запрошенный ресурс был окончательно перемещен в новое место, и любые будущие ссылки на этот ресурс должны использовать один из нескольких URI, возвращаемых с этим ответом. Если возможно, клиенты с возможностями редактирования ссылок должны автоматически изменять запрошенный адрес на адрес, возвращаемый с сервера. Если не указано иное, этот ответ также кэшируется. Новый постоянный URI должен быть возвращен в поле Location ответа. Если это не запрос HEAD, объект ответа должен содержать гиперссылку на новый URI и краткое описание. Если это не запрос GET или HEAD, браузер запрещает автоматическое перенаправление, если оно не подтверждено пользователем, поскольку условия запроса могут соответствующим образом измениться. Примечание. Для некоторых браузеров, использующих протокол HTTP/1.0, когда отправляемый ими запрос POST получает ответ 301, последующий запрос на перенаправление становится методом GET. |
| 302 | Запрошенный ресурс теперь временно отвечает на запросы от другого URI. Поскольку такие перенаправления являются временными, клиент должен продолжать отправлять запросы на исходный адрес в будущем. Этот ответ кэшируется, только если он указан в Cache-Control или Expires. Новый временный URI должен быть возвращен в поле «Местоположение» ответа. Если это не запрос 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, Cache-Control и/или Vary, если его значение может отличаться от значения, соответствующего другим предыдущим ответам на ту же переменную. Если этот запрос ответа использует строгую проверку кэша, то этот ответ не должен содержать другие заголовки объектов; в противном случае (например, условный запрос GET использует слабую проверку кэша) этому ответу запрещено содержать другие заголовки объектов; это позволяет избежать несоответствий между кэшированными содержимое объекта и обновленная информация заголовка объекта. Если ответ 304 указывает, что объект в настоящее время не кэшируется, система кэширования должна проигнорировать ответ и повторить запрос без ограничения. Если получен ответ 304, требующий обновления записи кэша, система кэширования должна обновить всю запись, чтобы отразить значения всех полей, которые были обновлены в ответе. |
| 305 | Доступ к запрошенному ресурсу должен осуществляться через указанный прокси. Информация URI указанного прокси будет указана в поле Местоположение.Получателю необходимо повторно отправить отдельный запрос для доступа к соответствующим ресурсам через этот прокси. Только исходный сервер может установить ответ 305. ПРИМЕЧАНИЕ. В RFC 2068 не указано, что ответ 305 предназначен для перенаправления одного запроса и может быть установлен только исходным сервером. Игнорирование этих ограничений может привести к серьезным последствиям для безопасности. |
| 306 | В последней версии спецификации код состояния 306 больше не используется. |
| 307 | Запрошенный ресурс теперь временно отвечает на запросы от другого URI. Поскольку такие перенаправления являются временными, клиент должен продолжать отправлять запросы на исходный адрес в будущем. Этот ответ кэшируется, только если он указан в Cache-Control или Expires. Новый временный URI должен быть возвращен в поле «Местоположение» ответа. Если это не запрос HEAD, объект ответа должен содержать гиперссылку на новый URI и краткое описание. Поскольку некоторые браузеры не могут распознать ответ 307, необходимо добавить указанную выше необходимую информацию, чтобы пользователи могли понять и сделать запросы доступа к новому URI. Если это не запрос GET или HEAD, браузер запрещает автоматическое перенаправление, если оно не подтверждено пользователем, поскольку условия запроса могут соответствующим образом измениться. |
| 400 | 1. Семантика неверна и текущий запрос не может быть понят сервером. Клиент не должен повторно отправлять этот запрос, если он не изменен. 2. Неверные параметры запроса. |
| 401 | Текущий запрос требует аутентификации пользователя. Ответ ДОЛЖЕН включать заголовок WWW-Authenticate, соответствующий запрошенному ресурсу, который запрашивает информацию о пользователе. Клиент может неоднократно отправлять запрос, содержащий соответствующую информацию заголовка авторизации. Если текущий запрос уже содержит сертификаты авторизации, ответ 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 в качестве типа контента. |
| 417 | Ожидаемое содержимое, указанное в заголовке запроса Expect, не может быть удовлетворено сервером, или сервер является прокси-сервером и имеет явное свидетельство того, что содержимое Expect не может быть удовлетворено на следующем узле текущего маршрута. |
| 421 | Количество подключений к серверу с IP-адреса текущего клиента превышает максимально допустимый диапазон сервера. Обычно под IP-адресом здесь подразумевается адрес клиента, видимый с сервера (например, адрес шлюза пользователя или адрес прокси-сервера). В этом случае в подсчете подключений может участвовать более одного конечного пользователя. |
| 422 | Количество подключений к серверу с IP-адреса текущего клиента превышает максимально допустимый диапазон сервера. Обычно под IP-адресом здесь подразумевается адрес клиента, видимый с сервера (например, адрес шлюза пользователя или адрес прокси-сервера). В этом случае в подсчете подключений может участвовать более одного конечного пользователя. |
| 422 | Запрос правильно отформатирован, но на него невозможно ответить из-за семантических ошибок. (RFC 4918 WebDAV) 423 LockedТекущий ресурс заблокирован. (RFC 4918 WebDAV) |
| 424 | Текущий запрос не выполнен из-за ошибки в предыдущем запросе, например PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Определен в проекте расширенных коллекций WebDav, но не отображается в «Протоколе сбора последовательностей 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). ). Примечание. Некоторые прокси-серверы возвращают ошибку 400 или 500 по истечении времени ожидания DNS-запроса. |
| 505 | Сервер не поддерживает или отказывается поддерживать версию HTTP, использованную в запросе. Это означает, что сервер не может или не желает использовать ту же версию, что и клиент. Ответ должен содержать сущность, описывающую, почему версия не поддерживается и какие протоколы поддерживает сервер. |
| 506 | Расширенный протоколом согласования прозрачного контента (RFC 2295), указывает на то, что на сервере имеется внутренняя ошибка конфигурации: запрошенный ресурс аргумента согласования настроен на использование самого себя при согласовании прозрачного контента и поэтому не является подходящим фокусом в процессе согласования. |
| 507 | Сервер не может хранить контент, необходимый для выполнения запроса. Это состояние считается временным. WebDAV (RFC 4918) |
| 509 | Сервер достиг предела пропускной способности. Это не официальный код статуса, но он до сих пор широко используется. |
| 510 | Стратегии, необходимые для получения ресурсов, еще не реализованы. (RFC 2774) |