Онлайн инструменты
Коды состояния 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, его значение должно соответствовать истинному количеству байт в возвращаемом диапазоне содержимого. Expires, Cache-Control и/или Vary, если их значения могут отличаться от значений других предыдущих ответов с теми же переменными. Этот ответ не должен содержать другие заголовки сущностей, если запрос использует сильную проверку кэша If-Range, и не должен содержать другие заголовки сущностей, если запрос использует слабую проверку кэша If-Range; это позволяет избежать несоответствий между кэшированным содержимым сущности и обновленной информацией заголовка сущности. В противном случае этот ответ ДОЛЖЕН содержать все поля заголовков сущностей, которые должны были быть возвращены в ответе 200. Если заголовки ETag или Last-Modified не совпадают в точности, кэш на стороне клиента должен запретить объединение содержимого, возвращенного в ответе 206, с любым ранее кэшированным содержимым. Любому кэшу, который не поддерживает заголовки Range и Content-Range, запрещено кэшировать содержимое, возвращаемое ответом 206.
207 Коды состояния, расширенные WebDAV(RFC 2518) Код состояния, расширенный WebDAV, означает, что последующее тело сообщения будет 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, 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-Authorisation для аутентификации. См. 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) 423 Заблокирован
424 Текущий запрос завершился неудачей из-за ошибки в предыдущем запросе, например PROPPATCH. (RFC 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). Примечание: Некоторые прокси-серверы возвращают ошибку 400 или 500, когда поиск DNS завершается.
505 Сервер не поддерживает или отказывается поддерживать версию HTTP, используемую в запросе. Это означает, что сервер не может или не хочет использовать ту же версию, что и клиент. Ответ должен содержать сущность, описывающую, почему версия не поддерживается и какие протоколы поддерживает сервер.
506 Расширено протоколом Transparent Content Negotiation Protocol (RFC 2295) для представления внутренней неправильной конфигурации сервера: запрашиваемый ресурс Negotiation Variant настроен на использование себя в Transparent Content Negotiation, и поэтому не является подходящим фокусом в процессе переговоров.
507 Сервер не может хранить содержимое, необходимое для выполнения запроса. Это состояние считается временным.WebDAV(RFC 4918)
509 Сервер достиг предела пропускной способности. Это не официальный код статуса, но он по-прежнему широко используется.
510 Политика, необходимая для получения ресурса, не была выполнена. (RFC 2774)
Доступ к записям: