Http коды состояния: Коды состояния HTTP — это… Что такое Коды состояния HTTP?

Коды состояния HTTP — это… Что такое Коды состояния HTTP?

301

Moved Permanently (русск. Перемещёно окончательно)
Появился в HTTP/1.0.

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоит забывать, что некоторые клиенты ошибочно меняют метод POST на GET после перехода на другой адрес.

Ответ может кэшироваться.

Если код состояния 301 получен после запроса GET или HEAD, то клиент должен запросить пользователя перед адресацией.

302

Found (русск. Найдено)
Введено в HTTP/1.0.

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые клиенты.

Код является примером того, как практика не соответствует стандартам. Спецификация HTTP/1.0 требовала от клиента осуществления временной переадресации («Moved temporarly» в оригинале), но популярные браузеры использовали 303 See other. Поэтому спецификация HTTP/1.1 (RFC 2068) добавила коды состояний 303 и 307, пытаясь избавиться от неоднозначности. Тем не менее, большинство веб-приложений по прежнему используют код 302, как если бы он был кодом 303.

303

See Other (русск. Смотреть другое)
Введено в HTTP/1.1.

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304

Not Modified (русск. Не изменено)
Появился в HTTP/1.0.

Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305

Use Proxy (русск. Использовать прокси)
Введено в HTTP/1.1.

Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).

306

Упомянуто в RFC 2616 (обновление HTTP/1.1).

Использовалось раньше. В настоящий момент зарезервировано.

307

Temporary Redirect (русск. Временное перенаправление) Введено в RFC 2616 (обновление HTTP/1.1).

Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.

4xx: Client Error

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Для облегчения запоминания значений кодов существуют приёмы иллюстративной мнемотехники (например, для диапазона 400 по 417 ^[1])

400

Bad Request (русск. Плохой запрос)
Появился в HTTP/1.0.

Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

401

Unauthorized (русск. Неавторизован)
Появился в HTTP/1.0.

Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.

402

Payment Required (русск. Необходима оплата )
Зарезервирован начиная с HTTP/1.1.

Предполагается использовать в будущем. В настоящий момент не используется.

403

Сервер вернул ошибку 403 при попытке просмотра директории cgi-bin, доступ к которой был запрещён

Forbidden (русск. Запрещено)
Появился в HTTP/1.0.

Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.

Сообщение 403 может возвращаться, если хозяин сайта по каким-то соображениям решил закрыть от пользователей часть информации. Кроме того, если веб-сервер не имеет прав доступа к запрошенному документу, он также вернёт код 403. Простая ситуация, когда страница может на самом деле не существовать, но сервер выдаст ошибку 403 (запрещено), а не 404 (не найдено): страница находится в директории foo, доступ к которой был запрещён веб-серверу — таким образом веб-сервер не может «знать», есть в этой директории такая страница, или нет.

Очень часто запрещается просмотр всех или некоторых директорий без главной страницы — в этом случае пользователю вывелся бы список файлов и каталогов в этой директории, а так ему возвращается ошибка 403.

404

Попытка запросить документ /fgsfds в Википедии приводит к ошибке 404. Тем не менее, программное обеспечение Википедии перенаправляет нас на соответствующую статью, которая могла бы существовать.

Not Found (русск. Не найдено)
Появился в HTTP/1.0.

Сервер понял запрос, но не нашёл соответствующего ресурса по указанному 410 вместо этого. Этот код может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

Ссылки

405

Method Not Allowed (русск. Метод не поддерживается)
Появился в HTTP/1.1.

Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов.

406

Not Acceptable (русск. Не приемлемо)
Появился в HTTP/1.1.

Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

407

Proxy Authentication Required (русск. Необходима авторизация прокси)
Появился в HTTP/1.1.

Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на обычном сервере.

408

Request Timeout (русск. Время ожидания истекло)
Появился в HTTP/1.1,

Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.

409

Conflict (русск. Конфликт)
Появился в HTTP/1.1.

Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410

Gone (русск. Удалён)
Появился в HTTP/1.1.

Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411

Length Required (русск. Необходима длина)
Появился в HTTP/1.1.

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

412

Precondition Failed (русск. Условие «ложно»)
Появился в HTTP/1.1.

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413

Request Entity Too Large (русск. Запрашиваемые данные слишком большие)
Появился в HTTP/1.1.

Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.

414

Request-URI Too Long (русск. Запрашиваемый URI слишком длинный)
Появился в HTTP/1.1.

Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415

Unsupported Media Type (русск. Неподдерживаемый тип данных)
Появился в HTTP/1.1.

По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416

Requested Range Not Satisfiable (русск. Запрашиваемый диапазон не достижим)
Введено в RFC 2616 (обновление HTTP/1.1).

В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417

Expectation Failed (русск. Ожидаемое ошибочно)
Введено в RFC 2616 (обновление HTTP/1.1).

По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422

Unprocessable Entity (русск. Необрабатываемый экзмепляр)
Введено в XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.

423

Locked (русск. Заблокировано)
Введено в

424

Failed Dependency (русск. Невыполненная зависимость)
Введено в 424.

426

Upgrade Required (русск. Необходимо обновление)
Введено в RFC 2817 для возможности перехода к

Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.

5xx: Server Error

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500

Internal Server Error (русск. Внутренняя ошибка сервера)
Появился в HTTP/1.0.

Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501

Not Implemented (русск. Не реализовано)
Появился в HTTP/1.0.

Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.

502

Bad Gateway (русск. Плохой шлюз)
Появился в HTTP/1.0.

Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.

503

Service Unavailable (русск. Сервис недоступен)
Появился в HTTP/1.0.

Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

504

Gateway Timeout (русск. Шлюз не отвечает)
Появился в HTTP/1.1.

Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505

HTTP Version Not Supported (русск. Версия HTTP не поддерживается)
Появился в HTTP/1.1.

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506

Variant Also Negotiates (русск. Вариант тоже согласован)
Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.

507

Insufficient Storage (русск. Закончилось место)
Введено в

510

Not Extended (русск. Не расширено)
Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.

Примечания

См. также

Ссылки

Код состояния HTTP — это… Что такое Код состояния HTTP?

301

Moved Permanently (русск. Перемещёно окончательно)
Появился в HTTP/1.0.

Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение. При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки. Не стоит забывать, что некоторые клиенты ошибочно меняют метод POST на GET после перехода на другой адрес.

Ответ может кэшироваться.

Если код состояния 301 получен после запроса GET или HEAD, то клиент должен запросить пользователя перед адресацией.

302

Found (русск. Найдено)
Введено в HTTP/1.0.

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение. При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI. При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые клиенты.

Код является примером того, как практика не соответствует стандартам. Спецификация HTTP/1.0 требовала от клиента осуществления временной переадресации («Moved temporarly» в оригинале), но популярные браузеры использовали 303 See other. Поэтому спецификация HTTP/1.1 (RFC 2068) добавила коды состояний 303 и 307, пытаясь избавиться от неоднозначности. Тем не менее, большинство веб-приложений по прежнему используют код 302, как если бы он был кодом 303.

303

See Other (русск. Смотреть другое)
Введено в HTTP/1.1.

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304

Not Modified (русск. Не изменено)
Появился в HTTP/1.0.

Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

305

Use Proxy (русск. Использовать прокси)
Введено в HTTP/1.1.

Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только родные HTTP-сервера (не прокси).

306

Упомянуто в RFC 2616 (обновление HTTP/1.1).

Использовалось раньше. В настоящий момент зарезервировано.

307

Temporary Redirect (русск. Временное перенаправление) Введено в RFC 2616 (обновление HTTP/1.1).

Запрашиваемый ресурс короткое время доступен только по другому URI (указывается в поле Location заголовка). Если был послан не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание. При использовании всех методов кроме GET и POST предварительно следует уведомить пользователя о временном изменении ссылки.

4xx: Client Error

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

Для облегчения запоминания значений кодов существуют приёмы иллюстративной мнемотехники (например, для диапазона 400 по 417 ^[1])

400

Bad Request (русск. Плохой запрос)
Появился в HTTP/1.0.

Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

401

Unauthorized (русск. Неавторизован)
Появился в HTTP/1.0.

Запрос требует идентификации пользователя. Клиент должен запросить имя и пароль у пользователя и передать их в записи WWW-Authenticate заголовка в следующем запросе. В случае ввода ошибочных данных сервер снова вернёт этот же статус.

402

Payment Required (русск. Необходима оплата )
Зарезервирован начиная с HTTP/1.1.

Предполагается использовать в будущем. В настоящий момент не используется.

403

Сервер вернул ошибку 403 при попытке просмотра директории cgi-bin, доступ к которой был запрещён

Forbidden (русск. Запрещено)
Появился в HTTP/1.0.

Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.

Сообщение 403 может возвращаться, если хозяин сайта по каким-то соображениям решил закрыть от пользователей часть информации. Кроме того, если веб-сервер не имеет прав доступа к запрошенному документу, он также вернёт код 403. Простая ситуация, когда страница может на самом деле не существовать, но сервер выдаст ошибку 403 (запрещено), а не 404 (не найдено): страница находится в директории foo, доступ к которой был запрещён веб-серверу — таким образом веб-сервер не может «знать», есть в этой директории такая страница, или нет.

Очень часто запрещается просмотр всех или некоторых директорий без главной страницы — в этом случае пользователю вывелся бы список файлов и каталогов в этой директории, а так ему возвращается ошибка 403.

404

Попытка запросить документ /fgsfds в Википедии приводит к ошибке 404. Тем не менее, программное обеспечение Википедии перенаправляет нас на соответствующую статью, которая могла бы существовать.

Not Found (русск. Не найдено)
Появился в HTTP/1.0.

Сервер понял запрос, но не нашёл соответствующего ресурса по указанному 410 вместо этого. Этот код может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

Ссылки

405

Method Not Allowed (русск. Метод не поддерживается)
Появился в HTTP/1.1.

Указанный клиентом метод нельзя применить к ресурсу. Сервер также должен передать в заголовке ответа поле Allow со списком доступных методов.

406

Not Acceptable (русск. Не приемлемо)
Появился в HTTP/1.1.

Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

407

Proxy Authentication Required (русск. Необходима авторизация прокси)
Появился в HTTP/1.1.

Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на обычном сервере.

408

Request Timeout (русск. Время ожидания истекло)
Появился в HTTP/1.1,

Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.

409

Conflict (русск. Конфликт)
Появился в HTTP/1.1.

Запрос не может выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

410

Gone (русск. Удалён)
Появился в HTTP/1.1.

Такой ответ сервер посылает, когда ресурс раньше был по указанному URI, но был удалён и теперь недоступен. Серверу в этом случае не известно и местоположение альтернативного документа (например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404.

411

Length Required (русск. Необходима длина)
Появился в HTTP/1.1.

Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

412

Precondition Failed (русск. Условие «ложно»)
Появился в HTTP/1.1.

Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413

Request Entity Too Large (русск. Запрашиваемые данные слишком большие)
Появился в HTTP/1.1.

Возвращается если сервер по каким-то причинам не может передать запрашиваемый объём информации. Если проблема временная, то сервер может в ответе указать в поле Retry-After время, по истечении которого можно повторить аналогичный запрос.

414

Request-URI Too Long (русск. Запрашиваемый URI слишком длинный)
Появился в HTTP/1.1.

Сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST.

415

Unsupported Media Type (русск. Неподдерживаемый тип данных)
Появился в HTTP/1.1.

По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе.

416

Requested Range Not Satisfiable (русск. Запрашиваемый диапазон не достижим)
Введено в RFC 2616 (обновление HTTP/1.1).

В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges.

417

Expectation Failed (русск. Ожидаемое ошибочно)
Введено в RFC 2616 (обновление HTTP/1.1).

По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса.

422

Unprocessable Entity (русск. Необрабатываемый экзмепляр)
Введено в XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.

423

Locked (русск. Заблокировано)
Введено в

424

Failed Dependency (русск. Невыполненная зависимость)
Введено в 424.

426

Upgrade Required (русск. Необходимо обновление)
Введено в RFC 2817 для возможности перехода к

Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection.

5xx: Server Error

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500

Internal Server Error (русск. Внутренняя ошибка сервера)
Появился в HTTP/1.0.

Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

501

Not Implemented (русск. Не реализовано)
Появился в HTTP/1.0.

Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод.

502

Bad Gateway (русск. Плохой шлюз)
Появился в HTTP/1.0.

Сервер в роли шлюза или прокси получил сообщение о неудачном выполнении промежуточной операции.

503

Service Unavailable (русск. Сервис недоступен)
Появился в HTTP/1.0.

Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным является сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов.

504

Gateway Timeout (русск. Шлюз не отвечает)
Появился в HTTP/1.1.

Сервер в роли шлюза или прокси не дождался ответа от вышестоящего сервера для завершения текущего запроса.

505

HTTP Version Not Supported (русск. Версия HTTP не поддерживается)
Появился в HTTP/1.1.

Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP.

506

Variant Also Negotiates (русск. Вариант тоже согласован)
Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

В результате ошибочной конфигурации выбранный вариант указывает сам на себя из-за чего процесс связывания прерывается.

507

Insufficient Storage (русск. Закончилось место)
Введено в

510

Not Extended (русск. Не расширено)
Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.

Примечания

См. также

Ссылки

Коды ошибок и состояния HTTP

При посещении сайта клиентское приложение подключается к веб-серверам по сетевому протоколу HTTP. Подобные сетевые соединения поддерживают отправку данных ответа от серверов к клиентам, в том числе содержимого веб-страниц, а также HTTP коды.

Включаемые в ответ HTTP-сервера данные представляют собой код, указывающий на результат обработки запроса. Эти коды состоят из трех цифр, разделенных на категории:

• 100-199: информационный статус;
• 200-299: статус успешного запроса;
• 300-399: статус редиректа;
• 400-499: ошибки клиента;
• 500-599: ошибки сервера.

В интернете или локальных сетях отображается только несколько кодов ошибок и состояний. Коды, связанные с ошибками, отображаются на веб-странице, выводимой в результате неудачного запроса, в то время как другие коды не показываются пользователям вовсе.

HTTP код 200 возникает, когда сервер успешно обработал запрос и передал контент обратно в браузер. Большинство HTTP-запросов завершается этим статусом. Пользователи редко видят этот код на экране, поскольку браузеры обычно отображают коды HTTP, если возникает какая-либо проблема.
Сервер не смог найти запрошенную страницу, файл или другой ресурс. Ошибка HTTP 404 указывает на то, что сетевое соединение между клиентом и сервером было успешно выполнено. Возникает, когда пользователь ввел в браузере неправильный URI, или администратор сервера удалил файл, не настроив редирект на новое местоположение. Чтобы устранить эту проблему, пользователи должны набрать правильный URL-адрес.
Сервер получил от клиента действительный запрос, но не смог обработать его. Ошибка HTTP 500 возникает, когда сервер сталкивается с каким-либо техническим сбоем. Например, нехваткой памяти или дискового пространства. Администратор сервера должен исправить эту проблему.
Этот код указывает, что сервер не может обработать входящий запрос. Некоторые серверы используют код ошибки HTTP 503 для указания ожидаемых сбоев, связанных с высоким потреблением ресурсов. Например, при превышении количества одновременно подключенных пользователей или лимита мощности центрального процессора, о которых обычно сообщается с помощью HTTP-500.
Указанный клиентом URI был перемещен в другое место с помощью HTTP-редиректа, который позволяет клиенту получить ресурс с нового местоположения. Браузеры автоматически следуют HTTP-редиректу 301 без необходимости вмешательства со стороны пользователя.
HTTP код 302 предназначен для случаев, когда ресурс перемещен временно, а не постоянно. Администратор сервера должен использовать HTTP 302 только в течение коротких периодов обновления (изменения) контента. Браузеры автоматически выполняют редирект 302, как и для кода 301. В версии HTTP 1.1 для указания временных редиректов был добавлен новый код 307.
Сервер обнаружил ошибку в данных протокола, полученных от клиента. Обычно это указывает на технический сбой на стороне клиента или повреждением данных в самой сети.
Эта ошибка возникает, когда клиенты запрашивают защищенный ресурс на сервере, но не аутентифицированы для доступа. Чтобы исправить ее, клиент должен войти на сервер с использованием логина и пароля.
Добавленный в версию 1.1 протокола код HTTP ответа 100 был разработан для более эффективного использования пропускной способности сети. Он позволяет серверам подтверждать готовность принимать большие запросы. Протокол Continue позволяет клиенту HTTP 1.1 отправлять небольшое специально сконфигурированное сообщение, запрашивающее ответ сервера с кодом 100, а затем дожидаться ответа до отправки запроса на дальнейшие действия. Клиенты и серверы HTTP 1.0 не используют этот код.
Сервер отправил ответ на запрос клиента, который содержит только информацию заголовка (то есть не содержит тела сообщения). Клиенты могут использовать HTTP код 204 для более эффективной обработки ответов сервера, избегая, например, ненужного обновления страниц.
Ошибка, возникающая в сети между клиентом и сервером, приводит к выводу этого кода ошибок HTTP. Это может быть связано с ошибками конфигурации в сетевом брандмауэре, маршрутизаторе или другом сетевом шлюзе.

Данная публикация представляет собой перевод статьи «HTTP Error and Status Codes Explained» , подготовленной дружной командой проекта Интернет-технологии.ру

HTTP коды состояния. Классы кодов состояния HTTP сервера

Привет, читатель блога ZametkiNaPolyah.ru! Продолжим знакомиться с протоколом HTTP в рубрике серверы и протоколы и ее разделе HTTP протокол. Сегодня мы с тобой начнем разбираться с кодами состояния HTTP сервера, а конкретно эта публикация познакомит тебя с классами кодов состояния HTTP сервера: ты разберешься с тем, как HTTP сервер отвечает на запросы твоего браузера и, что значат все эти цифры, которые периодически появляются в окне твоего бразуера. Оговорюсь сразу, что всего в стандарте HTTP пять классов кодов состояния, а каждый класс содержит несколько кодов состояния, которые могут быть расширены в зависимости от HTTP приложения.

HTTP коды состояний. Классы кодов состояния HTTP сервера

HTTP коды 1хх – информационные коды. HTTP коды 2хх – успешные коды. HTTP код 3хх – коды перенаправления. HTTP код 4хх – коды ошибок клиента. HTTP код 5хх – коды ошибок сервера.

Если вы хотите узнать всё про протокол HTTP, обратитесь к навигации по рубрике HTTP протокол. Код состояния – это элемент ответа HTTP сервера, который представляет собой три цифры, первая цифра показывает к какому классу состояния относится тот или иной код состояния. В HTTP насчитывают всего пять классов кодов состояний: 1хх, 2хх, 3хх, 4хх, 5хх. HTTP коды состояний расширяемы, любой разработчик сервера может добавлять свои коды. Каждый код состояния очень тесно связан с HTTP методами: если метод – это элемент HTTP запроса, то код состояния это HTTP ответ сервера, который означает то, как сервер понял запрос.

Давайте сведем HTTP коды состояний в одну таблицу, разделив коды по классам и дадим описание каждому классу состояния HTTP сервера.

Обычно помимо кода состояния сервер высылает пояснения клиенту в виде HTTP объекта и при помощи полей заголовка. Мы рассмотрели классы кодов состояний HTTP сервера, давайте теперь рассмотрим каждый класс и каждый код состояния HTTP протокола по отдельности.

Описание кодов ошибок интернета (404, 503 и тд) — кодов состояния HTTP — Поснов Андрей

Описание кодов

Информационные

В этот класс выделены коды, информирующие о процессе передачи. При работе через протокол версии 1.0 сообщения с такими кодами должны игнорироваться. В версии 1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

• 100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
• 101 Switching Protocols — сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.
• 102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

[править]Успех

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

• 200 OK — успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
• 201 Created — в результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется^{[источник не указан 380 дней]} ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.
• 202 Accepted — запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
• 203 Non-Authoritative Information — аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
• 204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
•  205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
•  206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)
•  207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектомmultistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
•  226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

Перенаправление

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303,305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

По последним стандартам клиент может производить перенаправление без запроса пользователя только если второй ресурс будет запрашиваться методом GET или HEAD^[6]. В предыдущих спецификациях говорилось, что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления^[13]. При всех перенаправлениях, если метод запроса был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом, чтобы в случае ошибки пользователь смог сам произвести переход.

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT)^[14]. Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

Поведение клиентов при различных перенаправлениях описано в таблице:

•  300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
•  301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
•  302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, приуправляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
•  303 See Other — документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
•  304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
•  305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
•  306 (зарезервировано) — использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
•  307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

Ошибка клиента

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

•  400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
•  401 Unauthorized — для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.
•  402 Payment Required — предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не дляхостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

Сервер вернул ошибку 403 при попытке просмотра директории «cgi-bin», доступ к которой был запрещён.

•  403 Forbidden — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
•  404 Not Found — самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
•  405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.
•  406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
•  407 Proxy Authentication Required — ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
•  408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-дискаили потеря связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
•  409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью методаPUT.Появился в HTTP/1.1.
•  410 Gone — такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.
•  411 Length Required — для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
•  412 Precondition Failed — возвращается, если ни одно из условных полей заголовка^{[неизвестный термин]} запроса не было выполнено. Появился в HTTP/1.1.
•  413 Request Entity Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.
•  414 Request-URL Too Long — сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.
•  415 Unsupported Media Type — по каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
•  416 Requested Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges^{[источник не указан 380 дней]}. Введено в RFC 2616 (обновление HTTP/1.1).
•  417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
•  422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
•  423 Locked — целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
•  424 Failed Dependency — реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
•  425 Unordered Collection — посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного^{[уточнить]}. Введено в черновике по WebDAV Advanced Collections Protocol^[15].
•  426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
•  428 Precondition Required — сервер указывает клиенту на необходимость использования в забросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.
•  429 Too Many Requests — клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.
•  431 Request Header Fields Too Large — Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.
•  449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.
•  451 Unavailable For Legal Reasons — доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google^[10], при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту».
•  456 Unrecoverable Error — возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных^{[источник не указан 380 дней]}. Введено корпорацией Microsoftдля WebDAV.

Ошибка сервера

Коды 5xx выделены под случаи неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

•  500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.
•  501 Not Implemented — сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
•  502 Bad Gateway — сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.
•  503 Service Unavailable — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.
•  504 Gateway Timeout — сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.
•  505 HTTP Version Not Supported — сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.
•  506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено вRFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
•  507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
•  509 Bandwidth Limit Exceeded — используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
•  510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено вRFC 2774 для дополнения протокола HTTP поддержкой расширений.
•  511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.

Описание кодов ошибок интернета (404, 503 и тд) — кодов состояния HTTP

Коды состояния HTTP, ответа веб сервера. Методы HTTP

Код состояния HTTP — это часть строки заголовка, ответа веб сервера на запрос клиента, информирующая о результате запроса и о том, что клиент должен предпринять далее. Думаю не все знают как выглядит заголовок ответа сервера, зато уверен, каждый, пользующийся интернетом, не раз сталкивались, со страницей 404 Not Found или 403 Forbadden. Это и есть, видимый пользователю результат, выдачи сервером, того или иного кода статуса в строке заголовке.

Коды состояния HTTP, разделены на 5 категорий. Клиент может быть не знаком с тем или иным кодом ответа HTTP, однако он должен отреагировать согласно категории кода. Итак протокол HTTP поддерживает следующие коды статуса, разделенные по категориям:

1xx: Information — информационные

100 Continue — Продолжать.

Сервер доволен данными в запросе клиента, можно продолжать передачу заголовков. Появился в протоколе версии HTTP/1.1.

101 Switching Protocols — Переключение протоколов.

Сервер предлагает выбрать другой протокол, более соответствующий данному ресурсу. Протоколы предлагаемый сервером, указываются в строке заголовка Update, если предложенный сервером протокол, устраивает клиента, он высылает новый запрос с указанием нового протокола. Появился в протоколе версии HTTP/1.1.

102 Processing — Обрабатывается.

Используется в протоколе WebDAV, работающем поверх HTTP протокола. Данный код статуса информирует клиента о том, что запрос принят, но на его обработку может понадобится определенное время, что-бы он ( клиент ), не сбрасывал соединение. Клиент в этом случае должен обнулить таймер и ожидать следующей команды.

2xx: Success — Успешное завершение

200 OK — Хорошо.

Запрос к ресурсу выполнен успешно. Данные, запрошенные клиентом, находятся в заголовке и/или в теле ответа. Появился в протоколе версии HTTP/1.0.

201 Created — Создано.

Запрос выполнен успешно, новый ресурс создан. В ответе сервера, в заголовке Location, указывается местоположение созданного ресурса. Кроме того, серверу рекомендуется указывать характеристики созданного ресурса, в заголовке ответа. Появился в протоколе версии HTTP/1.0.

202 Accepted — Принято.

Запрос принят, но еще в обработке. Появился в протоколе версии HTTP/1.0.

203 Non-Authoritative Information — Информация из неавторитетного источника.

Аналогично коду 200, но в данном случае информация может быть неактуальной, так как взята не из первоисточника. Появился в протоколе версии HTTP/1.1.

204 No Content — Отсутствует содержимое.

Сервер успешно обработал запрос, но не вернул содержимого. Появился в протоколе версии HTTP/1.0.

205 Reset Content — Сбросить содержимое.

Сервер успешно обработал запрос, но не вернул содержимого. В отличии от кода 204, данный код, требует от клиента, сбросить представление документа. Появился в протоколе версии HTTP/1.1.

206 Partial Content — Часть содержимого.

Сервер вернул результат запроса клиентом, части содержимого, с помощью заголовка range. Используется для докачки файлов или для многопоточной закачки. Появился в протоколе версии HTTP/1.1.

207 Multi-Status — Многостатусный.

Возвращаемое сервером тело сообщения, представляет из себя XML документ со статусами выполнения нескольких подзапросов. Используется в протоколе WebDAV.

226 IM Used — Использовано IM

Расширение HTTP для поддержки «дельта кодирования» ( delta encoding ). Заголовок A-IM принят, данные возвращаются согласно установленным параметрам.

3xx: Redirection — Редирект ( перенаправление )

Коды данной категории, сообщают клиенту, что для завершения запроса, ему необходимо выполнить дополнительный запрос, как правило по другому URI, соответствующий адрес указывается в строке Location, ответа сервера. Программа — клиент может совершать дополнительные запросы без участия пользователя, при условии что дополнительный запрос делается методами GET или HEAD.

Некоторые клиенты некорректно работают с редиректами 301 и 302, применяя в запросе ко второму ресурсу метод GET, несмотря на то, что первый запрос был сделан с использованием другого метода. В протоколе HTTP версии 1.1, вместо ответа статуса 302, были введены дополнительные коды ответов, 303 и 307. Изменять метод, необходимо только в случает ответа сервера со статусом 303, в остальных случаях использовать исходный метод.

300 Multiple Choices — Несколько вариантов выбора.

По запрошенному URI, существует несколько вариантов ресурса, различных по MIME типу. языку или другим признакам. В ответе сервера, передается список альтернатив, выбираемый клиентским приложением автоматически или самим пользователем. Появился в протоколе версии HTTP/1.0.

301 Moved Permanently — Перемещёно окончательно.

Запрошенный ресурс был окончательно перемещен на URI, указанный в строке заголовка Location, ответа сервера. Некоторые клиенты, при обработке данного кода, ведут себя некорректно, см. выше. Появился в протоколе версии HTTP/1.0.

302 Found — Найдено ( Moved Temporarily )

Данный код статуса сообщает клиенту, что ресурс временно доступен по другому URI, указанному в строке заголовка Location, заголовка ответа сервера. Данный код используется например, при согласовании содержимого ( Content Negotiation ), выполняемого сервером. Появился в протоколе версии HTTP/1.0.

303 See Other — Смотреть другое.

Документ из запрошенного URI, нужно запросить по адресу, указанному в строке заголовка Location, заголовка ответа сервера, используя метод GET, невзирая на то, каким методом был сделан первый запрос. Появился в протоколе версии HTTP/1.1.

304 Not Modified — Не изменялось.

Данный код выдается в случае запроса документа, методом GET, с использованием заголовков If-Modified-Since или If-None-Match, и документ не был изменен с указанного момента времени. Появился в протоколе версии HTTP/1.0.

305 Use Proxy — Использовать прокси сервер.

Запрос к ресурсу, должен выполняться через прокси-сервер., адрес которого, указан в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

307 Temporary Redirect — Временное перенаправление

Запрошенный ресурс временно доступен по URI, указанному в строке заголовка Location, заголовка ответа сервера. Появился в протоколе версии HTTP/1.1.

4xx: Client Error — Ошибка клиента

Коды данной категории служат для указание на ошибку со стороны клиента. При использовании любых методов запроса, кроме HEAD, сервера возвращает пользователю гипертекстовое пояснение по данной ошибке.

400 Bad Request — Плохой запрос.

Из-за синтаксической ошибки, запрос не был понят сервером. Появился в протоколе версии HTTP/1.0.

401 Unauthorized — Не авторизован.

Ресурс требует идентификации пользователя. Клиентское приложение запрашивает у пользователя данные для аутентификации ( имя, пароль ) и передает их на сервер в заголовке WWW-Authenticate. Если данные указаны не правильно, будет снова выдан этот-же код статуса. Появился в протоколе версии HTTP/1.0.

402 Payment Required — Необходима оплата.

Пока не используется. Появился в протоколе версии HTTP/1.1.

403 Forbidden — Запрещено.

Сервер отказал в доступе к запрошенному ресурсу ввиду ограничений. Ограничения могут быть любыми, установленными администратором сервера, или определенным веб приложением. Например, в целях безопасности, закрыт доступ к файлу, .htacces или .htpasswd или к закрытой директории сайта, или в случае, когда аутентификация должна производится через веб приложение ( например сайтовый движок ), ну или блокировка по IP адресу, в случае слишком частых обращений. Появился в протоколе версии HTTP/1.0.

404 Not Found — Не найдено.

Сервер не нашел запрошенный ресурс по указанному адресу. Кроме того данный код ответа можно использовать вместо 403, с целью, скрыть расположение документа, доступ к которому запрещен. Появился в протоколе версии HTTP/1.0.

405 Method Not Allowed — Метод не поддерживается.

Клиент попытался использовать метод, недопустимый для данного ресурса. Сервер передает в заголовке, строку Allow, содержащую список допустимых методов. Появился в протоколе версии HTTP/1.1.

406 Not Acceptable — Не приемлемо.

Запрошенный ресурс, не удовлетворяет, запрошенные характеристики. В случае, если запрос был сделан не методом HEAD, сервер вернет список допустимых характеристик запрошенного ресурса. Появился в протоколе версии HTTP/1.1.

407 Proxy Authentication Required — Необходима прокси авторизация.

Данный код статуса, аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Появился в протоколе версии HTTP/1.1.

408 Request Timeout — Время ожидания истекло.

Истек таймаут ожидания передачи данных, между сервером и клиентом. Появился в протоколе версии HTTP/1.1.

409 Conflict — Конфликт.

Конфликтная ситуация при обращении к ресурсу. Такое может произойти, например, при попытке одновременного изменения файла, методом PUT, несколькими клиентами. Появился в протоколе версии HTTP/1.1.

410 Gone — Удалён.

Данный ответ выдается в случае, если документ был по указанному URI, но в данный момент удален. Появился в протоколе версии HTTP/1.1.

411 Length Required — Необходима длина.

Этот код статуса говорит о том, что для данного URI, в заголовке запроса, должно быть указано значение в поле Content-Length. Появился в протоколе версии HTTP/1.1.

412 Precondition Failed — Условие «ложно.

Данный код выдается в случае, если ни одно из условных полей заголовка не было удовлетворено. Появился в протоколе версии HTTP/1.1.

413 Request Entity Too Large — Запрошены слишком большие данные.

Данный код выдается, если сервер по каким-либо причинам, не может передать, требуемый объем данных. Если это временная проблема, сервер может указать время, по истечении которого можно будет попробовать повторно запросить ресурс, в строке заголовка, Retry-After. Появился в протоколе версии HTTP/1.1.

414 Request-URI Too Long — Запрашиваемый URI слишком длинный.

Слишком длинная строка запроса. Такая ситуация может произойти, например в случае попытки, передать данные методом GET, вместо использования POST. Появился в протоколе версии HTTP/1.1.

415 Unsupported Media Type — Неподдерживаемый тип данных.

Сервер, по какой-то причине, отказался обрабатывать запрошенные данные, используемым методом. Появился в протоколе версии HTTP/1.1.

416 Requested Range Not Satisfiable — Запрашиваемый диапазон не достижим.

В строке заголовка запроса Range, установлен диапазон, выходящий за рамки запрошенного ресурса и отсутствует строка If-Range. Появился в протоколе версии HTTP/1.1.

417 Expectation Failed — Ожидаемое не приемлемо.

Сервер не может обработать строку заголовка запроса Expect. Появился в протоколе версии HTTP/1.1.

422 Unprocessable Entity — Необрабатываемый экземпляр.

Запрос принят, тип данных может быть обработан, синтаксис XML данных в теле запроса верен, но имеет место логическая ошибка, не позволяющая обработать запрос к ресурсу. Используется в протоколе WebDAV.

423 Locked — Заблокировано.

Запрошенный ресурс заблокирован от данного метода. Используется в протоколе WebDAV.

424 Failed Dependency — Невыполненная зависимость.

Выполнение запроса, может зависеть от результата выполнения, какой-либо другой операции, при невыполнении данного условия, будет выдан этот код статуса. Используется в протоколе WebDAV.

425 Unordered Collection — Беспорядочный набор.

Этот код статуса будет выдан в случае, если клиент отправил запрос обозначив положение в неотсортированной коллекции или используя порядок следования элементов отличный от серверного. Введено в черновике по WebDAV Advanced Collections Protocol.

426 Upgrade Required — Требуется обновление.

Указание сервера, клиенту, обновить протокол. Заголовок ответа, должен содержать правильно составленные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.

449 Retry With — Повторить с…

Выдается в случае поступления не достаточного количества информации для обработки запроса. В заголовок ответа сервера, помещается строка Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV.

5xx: Server Error — Ошибка на стороне сервера

Коды данной категории, предназначены для ситуаций, когда обработка запроса не возможна по вине сервера. Во всех случаях, кроме использования метода HEAD, сервер должен включать в тело ответа, объяснение для пользователя.

500 Internal Server Error — Внутренняя ошибка сервера.

Любая внутренняя ошибка на стороне сервера не подпадающая под остальные ошибки из категории 5хх. Появился в протоколе версии HTTP/1.0.

501 Not Implemented — Не реализовано.

Сервер не поддерживает, необходимых для обработки запроса, возможностей. ( например не поддерживается необходимый метод обработки ). Появился в протоколе версии HTTP/1.0.

502 Bad Gateway — Плохой шлюз.

Сервер, работающий в качестве прокси или шлюза, получил сообщение о неудачное в промежуточной операции. Появился в протоколе версии HTTP/1.0.

503 Service Unavailable — Сервис недоступен.

Сервер не в состоянии обрабатывать запросы клиентов по техническим причинам. Появился в протоколе версии HTTP/1.0.

504 Gateway Timeout — Истек таймаут ожидания ответа шлюза.

Проксирующий сервер или шлюз, не дождался ответа от вышестоящего сервера для завершения обработки запроса. Появился в протоколе версии HTTP/1.0.

505 HTTP Version Not Supported — Версия HTTP протокола не поддерживается.

Сервер не поддерживает, или не может обработать, указанную в заголовке версию HTTP протокола. Появился в протоколе версии HTTP/1.0.

506 Variant Also Negotiates — Вариант тоже согласован.

Из-за не верной конфигурации, выбранный вариант указывает сам на себя, в следствии чего, связывание прерывается. Добавлено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507 Insufficient Storage — Переполнение хранилища.

Недостаточно места для обработки текущего запроса. Возможно временная проблема. Используется в протоколе WebDAV.

509 Bandwidth Limit Exceeded — Пропускная возможность канала исчерпана.

Данный код статуса, используется в случае превышения веб площадкой, отведенного ей лимита, на потребляемый трафик. Данный код не описан ни одним RFC и используется только модулем bw/limited, панели веб-хостинга cPanel.

510 Not Extended — Нет расширения.

У сервера отсутствует расширение, которое пытается использовать клиентом. Сервер может передавать информацию, об имеющихся у него расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

Методы обработки запросов HTTP

HTTP метод — это основная операция, которую необходимо выполнить над ресурсом. В названии могут использоваться любые символы, кроме управляющих последовательностей и разделителей, как правило это короткое слово на английском языке. Имена методов HTTP зависимы от регистра.

Любой веб сервер обязан работать, по крайней мере с двумя методами GET и HEAD. Если сервер не смог определить метод, указанный в заголовке запроса клиента, он должен вернуть код статуса 501 (Not Implemented), если-же метод серверу известен, но неприменим к данному ресурсу, будет возвращен код статуса 405 (Method Not Allowed). Как в первом, так и во втором случае, сервер должен включить в свой ответ, заголовок Allow со списком методов, которые он поддерживает.

Метод OPTIONS

Данный метод используется для выяснения поддерживаемых веб-сервером возможностей или параметров соединения с конкретным ресурсом. Сервер включает в ответный запрос заголовок Allow, со списком поддерживаемых методов и возможно информацию о поддерживаемых расширениях. Тело запроса клиента, содержит информацию об интересующих его данных, но на данном этапе формат тела и порядок работы с ним, не определен, пока, сервер должен его игнорировать. С ответным запросом сервера, происходит аналогичная ситуация.

Что-бы выяснить возможности сервера, клиент должен указать в запросе URI, символ — «*«, то есть данный запрос к серверу выглядит как: OPTIONS * HTTP/1.1. Кроме прочего, данный запрос может быть использован для проверки работоспособности сервера и поддержки им протокола HTTP, версии 1.1. Результаты данного запроса не кэшируются.

Метод GET

Метод GET, применяется для запроса конкретного ресурса. Так-же с помощью GET, может быть инициирован некий процесс, при этом, в тело ответа, включается информация о ходе выполнения инициированного запросом действия.

Параметры для выполнения запроса, передаются в URI запрашиваемого ресурса, после символа «?«. Запрос в таком случае выглядит примерно так: GET /some/resource?param1=val1&param2=val2 HTTP/1.1.

Как установлено в стандарте HTTP, запросы методом GET, являются идемпотентными, то есть, повторная отправка одного и того-же запроса, методом GET, должна приводить к одному и тому-же результату, в случае, если сам ресурс, в промежутках между запросами, изменен не был, что позволяет кэшировать результаты, выдаваемые на запрос методом GET.

Кроме вышесказанного, существуют еще два вида метода GET, это:
условный GET, содержащий заголовки If-Modified-Since, If-Match, If-Range и им подобные,
Частичный GET, содержащий заголовок Range с указанием байтового диапазона данных, которые сервер должен отдать. Данный вид запроса используется для докачки и организации многопоточных закачек.

Порядок работы с этими подвидами запроса GET, стандартами определен отдельно.

Метод HEAD

Данный метод, аналогичен методу GET, с той лишь разницей, что сервер не отправляет тело ответа. Метод HEAD, как правило используется для получения метаданных ресурса, проверки URL ( есть-ли указанный ресурс на самом деле ) и для выяснения факта изменения ресурса с момента последнего обращения к нему.

Заголовки ответа могут быть закэшированы, при несоответствии метаданных и информации в кэше, копия ресурса помечается как устаревшая.

Метод POST

Метод POST, используется для передачи пользовательских данных на сервер, указанному ресурсу. Примером может послужить HTML форма с указанным атрибутом Method=»POST», для отправки комментария к статье. После заполнения необходимых полей формы, пользователь жмет кнопку «Отправить» и данные, методом POST, передаются серверному сценарию, который в свою очередь выводит их на странице комментариев. Таким-же образом, с помощью метода POST, можно передавать файлы.

В отличии от GET, метод POST, не является идемпотентным, то есть неоднократное повторение запроса POST, может выдавать разные результаты. В нашем случае, будет появляться новая копия комментария при каждом запросе.

Если в результате запроса методом POST, возвращается код 200 (Ok) или 204 (No Content), в тело ответа сервера, добавляется сообщение о результате выполнения запроса. Например, если был создан ресурс, сервер вернет 201 (Created), указав при этом URI созданного ресурса в заголовке Location.

Ответы сервера, на выполнение метода POST, не кэшируются.

Метод PUT

Используется для загрузки данных запроса на указанный URI. В случае отсутствия ресурса по указанному в заголовке URI, сервер создает его и возвращает код статуса 201 (Created), если ресурс присутствовал и был изменен в результате запроса PUT, выдается код статуса 200 (Ok) или 204 (No Content). Если какой-то из переданных серверу заголовков Content-*, не опознан или не может быть использован в данной ситуации, сервер возвращает статус ошибки 501 (Not Implemented).

Главное различие методов PUT и POST в том, что при методе POST, предполагается, что по указанному URI, будет производиться обработка, передаваемых клиентом данных, а при методе PUT, клиент подразумевает, что загружаемые данные уже соответствуют ресурсу, расположенному по данному URI.

Ответы сервера при методе PUT не кэшируются.

Метод PATCH

Работает аналогично методу PUT, но применяется только к определенному фрагменту ресурса.

Метод DELETE

Удаляет ресурс, расположенный по заданному URI.

Метод TRACE

При запросе методом TRACE, клиент может увидеть, какие изменения были сделаны в запросе, промежуточными серверами.

Метод LINK

Связывает указанный ресурс с другим ресурсом.

Метод UNLINK

Снимает привязку одного ресурса к другому.

Состояние ответа и коды ошибок

При использовании нашего API вы можете столкнуться с определенными кодами status и error , которые необходимо понять или устранить. Эта страница содержит список всех кодов с подробным описанием и действиями, которые необходимо предпринять, если вы хотите решить проблему.

Найдите кодовое имя

Используйте поле поиска на странице или функцию веб-браузера «Найти на странице», чтобы быстро найти искомое кодовое имя.

Коды состояния HTTP

Каждая HTTP-транзакция имеет код состояния, возвращаемый сервером, чтобы определить, как сервер обработал транзакцию. Наиболее частые статусы, с которыми вы могли столкнуться: 200 OK и 404 Not Found . Ознакомьтесь со списком кодов состояния HTTP, чтобы узнать больше.

Коды статуса API

Помимо стандартного кода состояния HTTP, объект состояния может быть возвращен как часть ответного сообщения API, отчета о доставке или журнала сообщений.

Пример объекта статуса:

  {
   "groupId": 3,
   "groupName": "ДОСТАВЛЕНО",
   "id": 5,
   "name": "DELIVERED_TO_HANDSET",
   "description": "Сообщение доставлено на трубку"
}  

Коды общего состояния

PENDING (id группы: 1) — общие коды состояний

Сообщение обработано и отправлено следующему экземпляру, то есть оператору мобильной связи.

НЕ ДОСТАВЛЯЕТСЯ (идентификатор группы: 2) — общие коды состояния

Сообщение не было доставлено.

ДОСТАВЛЕНО (идентификатор группы: 3) — общие коды статуса

Сообщение успешно обработано и доставлено.

EXPIRED (group id: 4) — общие коды статуса

Сообщение было отправлено, и срок его действия либо истек из-за того, что истек срок его действия (наша платформа по умолчанию составляет 48 часов), либо в отчете о доставке от оператора истек срок действия как окончательный.

REJECTED (group id: 5) — общие коды статуса

Сообщение было получено, но либо было отклонено Infobip, либо оператор вернул статус REJECTED как окончательный.

Коды состояния голоса

ОТКЛОНЕН (идентификатор группы: 5) — Голосовые коды статуса

Сообщение было получено, но либо было отклонено Infobip, либо оператор вернул , отклонил как окончательный статус.

Коды состояния push-уведомлений

UNDELIVERABLE (group id: 2) — коды состояния push-уведомлений

Сообщение не было доставлено.

REJECTED (group id: 5) — коды статуса push-уведомлений

Сообщение было получено, но либо оно было отклонено Infobip, либо оператор вернул отклонение в качестве окончательного статуса.

Коды ошибок

Объект ошибки может быть возвращен как часть ответа на отправленное сообщение или ответа на отчет о доставке.

Пример объекта ошибки:

  {
   "groupId": 0,
   "groupName": "ОК",
   "id": 0,
   "name": "NO_ERROR",
   "description": "Нет ошибки",
   "постоянный": ложь
}
    

Коды общих ошибок

OK (идентификатор группы: 0) — общие коды ошибок

Запрос был успешно выполнен.

HANDSET_ERRORS (идентификатор группы: 1) — общие коды ошибок

Запрос не был выполнен из-за проблем с телефоном.

USER_ERRORS (идентификатор группы: 2) — общие коды ошибок

Произошла ошибка пользователя.

OPERATOR_ERRORS (идентификатор группы: 3) — общие коды ошибок

Запрос не был выполнен из-за проблем оператора.

Коды голосовых ошибок

OK (идентификатор группы: 0) — коды ошибок голосовой

Запрос был успешно выполнен.

HANDSET_ERRORS (идентификатор группы: 1) — коды голосовых ошибок

Запрос не был выполнен из-за проблем с телефоном.

OPERATOR_ERRORS (идентификатор группы: 3) — коды голосовых ошибок

Запрос не был выполнен из-за проблем оператора.

RFC 6585 — Дополнительные коды состояния HTTP

[Документы] [txt | pdf] [draft-nottingha…] [Tracker] [Diff1] [Diff2]

ПРЕДЛАГАЕМЫЙ СТАНДАРТ

Инженерная группа Интернета (IETF) М. Ноттингем
Запрос комментариев: 6585 Rackspace
Обновления: 2616 R. Fielding
Категория: Стандарты Track Adobe
ISSN: 2070-1721 апреля 2012 г.


                      Дополнительные коды состояния HTTP

Аннотация

   Этот документ определяет дополнительный протокол передачи гипертекста (HTTP).
   коды состояния для множества распространенных ситуаций.Статус этой памятки

   Это документ Internet Standards Track.

   Этот документ является продуктом Инженерной группы Интернета.
   (IETF). Он представляет собой консенсус сообщества IETF. Оно имеет
   получил публичное рецензирование и был одобрен к публикации
   Инженерная группа управления Интернетом (IESG). Дополнительная информация о
   Интернет-стандарты доступны в разделе 2 RFC 5741.

   Информация о текущем статусе этого документа, исправлениях,
   а как оставить отзыв о нем можно узнать на
   http: // www.rfc-editor.org/info/rfc6585.

Уведомление об авторских правах

   Авторские права (c) IETF Trust 2012 г. и лица, указанные как
   авторы документа. Все права защищены.

   Этот документ регулируется BCP 78 и Правовой нормой IETF Trust.
   Положения, касающиеся документов IETF
   (http://trustee.ietf.org/license-info) действует на дату
   публикация этого документа. Пожалуйста, просмотрите эти документы
   внимательно, поскольку они уважительно описывают ваши права и ограничения
   к этому документу. Компоненты кода, извлеченные из этого документа, должны
   включить упрощенный текст лицензии BSD, как описано в разделе 4.е из
   Правовые положения Trust и предоставляются без гарантии, как
   описана в упрощенной лицензии BSD.









Nottingham & Fielding Standards Track [Страница 1] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


Содержание

   1. Введение ............................................... ..... 2
   2. Требования ............................................... ..... 2
   3. 428 Требуется предварительное условие ....................................... 2
   4. 429 Too Many Requests ........................................... 3
   5. 431 Слишком большие поля заголовка запроса ............................. 4
   6. 511 сетевая аутентификация ............................. 4
   7. Соображения безопасности ......................................... 6
   8. Вопросы IANA ............................................. 7
   9. Ссылки ............................................... ....... 7
   Приложение A. Благодарности....................................... 9
   Приложение B. Проблемы, возникающие при использовании Captive Portal ....................... 9

1. Введение

   В этом документе указаны дополнительные коды состояния HTTP [RFC2616] для
   различные общие ситуации, чтобы улучшить взаимодействие и избежать
   путаница при использовании других, менее точных кодов состояния.

   Обратите внимание, что эти коды состояния не являются обязательными; серверы не могут потребоваться
   чтобы поддержать их. Однако, поскольку клиенты будут обращаться с неизвестным статусом
   коды как общая ошибка того же класса (например,г., 499 рассматривается как
   400, если он не распознается), их можно безопасно развернуть с помощью существующих
   серверы (см. [RFC2616] раздел 6.1.1 для получения дополнительной информации).

2. Требования

   Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
   «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
   документ следует интерпретировать, как описано в [RFC2119].

3. 428 Требуется предварительное условие

   Код состояния 428 указывает, что исходный сервер требует
   просьба быть условной.Его типичное использование - избежать проблемы "потерянного обновления", когда клиент
   ПОЛУЧАЕТ состояние ресурса, изменяет его и отправляет обратно на сервер,
   когда тем временем третья сторона изменила состояние на сервере,
   приводящий к конфликту. Требуя, чтобы запросы были условными,
   сервер может гарантировать, что клиенты работают с правильными копиями.

   В ответах с этим кодом состояния СЛЕДУЕТ объяснять, как повторно отправить
   запрос успешно. Например:

   HTTP / 1.1 428 Требуется предварительное условие
   Тип содержимого: текст / html



Nottingham & Fielding Standards Track [Страница 2] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


   
      
         
      
      
         
 Требуется предварительное условие 
         
 Этот запрос должен быть условным;
         попробуйте использовать «If-Match».
 
   

   Ответы с кодом состояния 428 НЕ ДОЛЖНЫ храниться в кэше.

4. 429 Слишком много запросов

   Код состояния 429 указывает на то, что пользователь отправил слишком много
   запросы за заданный промежуток времени («ограничение скорости»).

   Представления ответа ДОЛЖНЫ включать подробности, объясняющие
   условие и МОЖЕТ включать заголовок Retry-After, указывающий, как долго
   ждать, прежде чем делать новый запрос.

   Например:

   HTTP / 1.1 429 Слишком много запросов
   Тип содержимого: текст / html
   Повторить после: 3600

   
      
         
      
      
         
 Слишком много запросов 
         
 Я разрешаю только 50 запросов в час к этому веб-сайту за
            авторизованный пользователь.Повторите попытку позже. 
      
   

   Обратите внимание, что эта спецификация не определяет, как исходный сервер
   идентифицирует пользователя и как подсчитывает запросы. Например,
   исходный сервер, который ограничивает частоту запросов, может сделать это на основе
   количество запросов для каждого ресурса по всему серверу,
   или даже среди множества серверов. Точно так же он может идентифицировать пользователя
   с помощью учетных данных аутентификации или cookie с отслеживанием состояния.

   Ответы с кодом состояния 429 НЕ ДОЛЖНЫ храниться в кэше.Nottingham & Fielding Standards Track [Страница 3] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


5. 431 поле заголовка запроса слишком велико

   Код состояния 431 указывает на то, что сервер не желает обрабатывать
   запрос, потому что его поля заголовка слишком велики. Запрос МОЖЕТ
   быть повторно отправленным после уменьшения размера полей заголовка запроса.

   Его можно использовать как тогда, когда набор полей заголовка запроса в сумме равен
   слишком большой, и когда одно поле заголовка имеет ошибку.В последнем
   случае, представление ответа ДОЛЖНО указывать, какое поле заголовка
   был слишком большим.

   Например:

   HTTP / 1.1 431 Слишком большие поля заголовка запроса
   Тип содержимого: текст / html

   
      
         
      
      
         
 Слишком большие поля заголовка запроса 
         
 Заголовок "Пример" слишком большой. 
      
   

   Ответы с кодом состояния 431 НЕ ДОЛЖНЫ храниться в кэше.6. 511 сетевая аутентификация требуется

   Код состояния 511 указывает, что клиенту необходимо пройти аутентификацию.
   чтобы получить доступ к сети.

   Представление ответа ДОЛЖНО содержать ссылку на ресурс, который
   позволяет пользователю отправлять учетные данные (например, с помощью HTML-формы).

   Обратите внимание, что ответ 511 НЕ ДОЛЖЕН содержать вызов или
   сам интерфейс входа в систему, потому что браузеры будут отображать логин
   интерфейс как связанный с первоначально запрошенным URL,
   что может вызвать путаницу.Статус 511 НЕ ДОЛЖЕН генерироваться исходными серверами; это
   предназначен для использования путем перехвата прокси, которые вставляются как
   средства контроля доступа к сети.

   Ответы с кодом состояния 511 НЕ ДОЛЖНЫ храниться в кэше.





Трек стандартов Nottingham & Fielding [Страница 4] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


6.1. Код состояния 511 и порталы авторизации

   Код состояния 511 предназначен для устранения проблем, вызванных
   "скрытые порталы" для программного обеспечения (особенно агентов, не связанных с браузером), которое
   ожидая ответа от сервера, к которому был сделан запрос, а не
   промежуточная сетевая инфраструктура.Он не предназначен для
   поощрять развертывание захваченных порталов - только для ограничения ущерба
   вызванные ими.

   Оператор сети, желающий потребовать аутентификации, принятия
   условий или другое взаимодействие с пользователем перед предоставлением доступа обычно
   делает это путем выявления клиентов, которые этого не сделали ("неизвестно
   клиентов "), используя свои адреса управления доступом к среде (MAC).

   Неизвестные клиенты затем блокируют весь трафик, кроме TCP.
   порт 80, который отправляется на HTTP-сервер («сервер входа в систему»)
   посвященный "входу в систему" неизвестных клиентов, и, конечно, трафик на
   сам логин-сервер.Например, пользовательский агент может подключиться к сети и сделать
   следующий HTTP-запрос на TCP-порт 80:

   ПОЛУЧИТЬ /index.htm HTTP / 1.1
   Хост: www.example.com

   После получения такого запроса сервер входа в систему сгенерирует 511
   ответ:

   HTTP / 1.1 511 Требуется сетевая аутентификация
   Тип содержимого: текст / html

   
      
         
         <мета http-Equiv = "обновить"
               content = "0; url = https: // войти.example.net / ">
      
      
         
 Вам необходимо 
         пройти аутентификацию в локальной сети , чтобы получить
         доступ. 
      
   

   Здесь код состояния 511 гарантирует, что клиенты, не использующие браузер, не будут
   интерпретировать ответ как полученный от исходного сервера, а META
   Элемент HTML перенаправляет пользовательский агент на сервер входа в систему.




Nottingham & Fielding Standards Track [Страница 5] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


7.Соображения безопасности

7.1. 428 Требуется предварительное условие

   Код состояния 428 не является обязательным; клиенты не могут полагаться на его использование для
   предотвращение конфликтов «потерянного обновления».

7.2. 429 Слишком много запросов

   Когда сервер находится под атакой или просто получает очень большое число
   запросов от одной стороны, каждый отвечает со статусом 429
   код будет потреблять ресурсы.

   Следовательно, серверы не обязаны использовать код состояния 429; когда
   ограничивая использование ресурсов, может быть более целесообразным просто отбросить
   подключений или предпринять другие шаги.7.3. 431 Слишком большие поля заголовка запроса

   Серверы не обязаны использовать код состояния 431; когда под
   атаки, может быть более подходящим просто разорвать соединение или
   другие шаги.

7.4. 511 Требуется сетевая аутентификация

   Обычно ответ с кодом состояния 511 не приходит.
   с исходного сервера, указанного в URL-адресе запроса. Это представляет
   много проблем с безопасностью; например, атакующий посредник может быть
   вставка файлов cookie в пространство имен исходного домена может быть
   наблюдение за куки-файлами или учетными данными HTTP-аутентификации, отправленными из
   пользовательский агент и так далее.Однако эти риски не уникальны для кода состояния 511; в другом
   слов, скрытый портал, который не использует этот код состояния, вводит
   те же вопросы.

   Также обратите внимание, что авторизованные порталы, использующие этот код состояния на защищенной
   Соединение на уровне сокетов (SSL) или Transport Layer Security (TLS)
   (обычно порт 443) вызывает ошибку сертификата на клиенте.












Трек стандартов Nottingham & Fielding [Страница 6] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


8.Соображения IANA

   Реестр кодов состояния HTTP обновлен следующим:
   записи:

      Значение: 428
      Описание: Требуется предварительное условие
      Ссылка: [RFC6585]

      Значение: 429
      Описание: Слишком много запросов
      Ссылка: [RFC6585]

      Значение: 431
      Описание: Слишком большие поля заголовка запроса
      Ссылка: [RFC6585]

      Значение: 511
      Описание: требуется сетевая аутентификация
      Ссылка: [RFC6585]

9. Ссылки

9.1. Нормативные ссылки

   [RFC2119] Брэднер, С., "Ключевые слова для использования в RFC для обозначения
               Уровни требований », BCP 14, RFC 2119, март 1997 г.

   [RFC2616] Филдинг, Р., Геттис, Дж., Могул, Дж., Фристик, Х.,
               Масинтер, Л., Лич, П., и Т. Бернерс-Ли, "Гипертекст
               Протокол передачи - HTTP / 1.1 », RFC 2616, июнь 1999 г.

9.2. Информативные ссылки

   [CORS] van Kesteren, A., Ed., "Cross-Origin Resource Sharing",
               W3C Working Draft WD-cors-20100727, июль 2010 г.,
               .

   [Favicon] Википедия, «Favicon», март 2012 г.,
               .

   [OAuth3.0] Хаммер-Лахав, Э., Ред., Рекордон, Д., и Д. Хардт, "The
               Протокол авторизации OAuth 2.0 ", Работа в процессе,
               Март 2012 г.






Трек стандартов Nottingham & Fielding [Страница 7] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


   [P3P] Маркиори, М., Ред. "Платформа настроек конфиденциальности
               1.0 (P3P1.0) Specification », Рекомендация W3C
               REC-P3P-20020416, апрель 2002 г.,
               .

   [RFC4791] Дабу, К., Дерюиссо, Б., и Л. Дюссо,
               «Расширения календаря для WebDAV (CalDAV)», RFC 4791,
               Март 2007 г.

   [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed".
               Разработка и управление версиями (WebDAV) », RFC 4918, июнь 2007 г.[ВИДЖЕТЫ] Касерес, М., ред., "Упаковка виджетов и XML
               Конфигурация », Рекомендация W3C REC-widgets-20110927,
               Сентябрь 2011 г., .

   [WebFinger] Проект WebFinger, «WebFingerProtocol (черновик)»,
               Январь 2010 г., .
































Ноттингем энд Филдинг Стандарты Track [Страница 8] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


Приложение.Благодарности

   Спасибо Яну Алгермиссену и Джулиану Решке за их предложения
   и обратная связь.

Приложение B. Проблемы, возникающие при использовании Captive Portals

   Поскольку клиенты не могут отличить ответ портала от
   тот из HTTP-сервера, с которым они намеревались общаться,
   возникает ряд вопросов. Код состояния 511 предназначен для помощи
   смягчить некоторые из них.

   Одним из примеров является "favicon.ico" [Favicon], обычно используемый браузерами.
   для идентификации сайта, к которому осуществляется доступ. Если значок для данного сайта
   загружается с адаптивного портала вместо предполагаемого сайта (например,грамм.,
   поскольку пользователь не прошел аутентификацию), он часто "застревает" в
   кеш браузера (большинство реализаций агрессивно кешируют значки)
   вне сеанса портала, так что кажется, что портал
   favicon "захватил" законный сайт.

   Еще одна проблема, связанная с браузером, возникает, когда Платформа конфиденциальности
   Настройки [P3P] поддерживаются. В зависимости от того, как это реализовано,
   возможно, браузер может интерпретировать ответ портала для
   p3p.xml в качестве файла сервера, что приводит к политике конфиденциальности (или
   их отсутствие), рекламируемые порталом, интерпретируются как применяющие
   на предполагаемый сайт.Другие веб-протоколы, такие как WebFinger
   [WebFinger], совместное использование ресурсов из разных источников [CORS] и Open
   Авторизация [OAuth3.0] также может быть уязвима для таких проблем.

   Хотя протокол HTTP наиболее широко используется в веб-браузерах, все большее число
   приложений, не просматривающих страницы, используют его в качестве протокола подложки. За
   пример, Распределенная веб-разработка и управление версиями (WebDAV) [RFC4918]
   и расширения календаря для WebDAV (CalDAV) [RFC4791] используют HTTP
   в качестве основы (для удаленного создания и ведения календаря соответственно).Использование этих приложений из-за адаптивного портала может привести к
   ложные ошибки, представляемые пользователю, которые могут привести к
   искажение контента в крайних случаях.

   Аналогичным образом могут пострадать и другие небраузерные приложения, использующие HTTP.
   а также, например, виджеты [WIDGETS], обновления программного обеспечения и другие
   специализированное программное обеспечение, такое как клиенты Twitter и iTunes Music
   Хранить.

   Следует отметить, что иногда считается, что использование HTTP
   перенаправление для прямого трафика на портал решает эти проблемы.Однако, поскольку многие из них используют перенаправления "подписки", это не
   хорошее решение.




Трек стандартов Nottingham & Fielding [Страница 9] 

RFC 6585 Дополнительные коды состояния HTTP, апрель 2012 г.


Адреса авторов

   Марк Ноттингем
   Rackspace

   Электронная почта: [email protected]
   URI: http://www.mnot.net/


   Рой Т. Филдинг
   Adobe Systems Incorporated
   345 Park Ave.
   Сан-Хосе, Калифорния 95110
   США

   Электронная почта: [email protected]
   URI: http: // roy.gbiv.com/


































Nottingham & Fielding Standards Track [Страница 10]

 

Разметка HTML, созданная rfcmarkup 1.129d, доступная по адресу
https://tools.ietf.org/tools/rfcmarkup/

Коды состояния HTTP Rails | Найдите код состояния Rails HTTP

httpstat.нас

Это супер простой сервис для генерации различных кодов HTTP.

Это полезно для тестирования того, как ваши собственные сценарии справляются с различными ответами.

Просто добавьте код статуса, который вы хотите, в URL-адрес, например:
httpstat.us/200

Мы вернем такой ответ:

HTTP / 1.1 {код состояния} {описание статуса}
Тип содержимого: текст / простой или приложение / json
Content-Length: {something}
{любые персонализированные заголовки ответов}

{код статуса} {описание статуса}
{список любых добавленных нами пользовательских заголовков ответов}

Чтобы получить ответ JSON, вам необходимо убедиться, что заголовок Accept содержит «application / json».Затем мы закодируем ответ в формате JSON и соответствующим образом отправим заголовок Content-Type.

Если вам нужна задержка ответа, добавьте строку запроса сна (время в мс, максимум 5 минут *), например:
httpstat.us/200?sleep=5000

* При использовании размещенного экземпляра время ожидания фактически составляет 230 секунд, что является максимальным временем ожидания, разрешенным веб-приложением Azure (см. Сообщение в этой ветке). Если вы разместите его самостоятельно в IIS / IIS Express, у вас не будет этого ограничения.

Вот все коды, которые мы поддерживаем (и любые особые примечания):

100

Продолжить

101

Протоколы переключения

102

Обработка

103

Ранние подсказки

200

ОК

201

Создано

202

Принято

203

Неавторизованная информация

204

Нет содержимого

205

Сбросить содержимое

206

Частичное содержимое

300

Множественный выбор

301

Постоянно перемещен

302

Найдено

303

См. Другие

304

Не изменено

305

Использовать прокси

306

Не используется

307

Временное перенаправление

308

Постоянное перенаправление

400

Плохой запрос

401

Неавторизованный

402

Требуется оплата

403

Запрещено

404

Не найдено

405

Недопустимый метод

406

Неприемлемо

407

Требуется проверка подлинности прокси

408

Время ожидания запроса

409

Конфликт

410

Исчез

411

Требуемая длина

412

Ошибка предварительного условия

413

Слишком большой объект запроса

414

Запрос-URI слишком длинный

415

Неподдерживаемый тип носителя

416

Запрошенный диапазон не выполняется

417

Ожидание не выполнено

418

Я чайник

421

Неверно направленный запрос

422

Непроцессная сущность

423

Закрыт

425

Слишком рано

426

Требуется обновление

428

Требуется предварительное условие

429

Слишком много запросов

431

Слишком большие поля заголовка запроса

451

Недоступно по юридическим причинам

500

Внутренняя ошибка сервера

501

Не реализовано

502

Плохой шлюз

503

Служба недоступна

504

Тайм-аут шлюза

505

Версия HTTP не поддерживается

506

Вариант также обсуждает

507

Недостаточно памяти

511

Требуется сетевая аутентификация

520

Веб-сервер возвращает неизвестную ошибку

522

Превышено время ожидания соединения

524

Истекло время ожидания

Если вам нужно включить CORS, просто добавьте / cors в конце URL-адреса.Например: httpstat.us/200/cors.

Если вы отправите любой другой трехзначный номер, которого нет в этом списке, мы его тоже вернем. Или отправьте нам запрос на включение, чтобы добавить полную поддержку нового кода.

Наслаждайтесь!

Создан
Аарон Пауэлл
а также
Татхам Одди
, размещенный на
Веб-приложение Azure
.

Мы не собираем и не храним никаких данных о ваших запросах.

Список общих кодов состояния HTTP

Каждая транзакция HTTP имеет код состояния, отправляемый сервером
чтобы определить, как сервер обработал транзакцию. Вот список
самые распространенные.

Список общих кодов состояния HTTP

1. 200 ОК

2. 300 Множественный выбор

3. 301 перемещен навсегда

4. 302 Найдено

5. 304 Без изменений

6. 307 Временное перенаправление

7. 400 неверный запрос

8. 401 Неавторизованный

9. 403 Запрещено

10. 404 Не найдено

11. 410 ушел

12. 500 Внутренняя ошибка сервера

13. 501 Не реализовано

14. 503 Служба недоступна

15. 550 В доступе отказано

Код состояния HTTP — 200 ОК

Запрос успешно выполнен.Информация, возвращенная с ответом
зависит от метода, использованного в запросе.

Вернуться к началу

Код состояния HTTP — 300 вариантов выбора

Запрошенный ресурс имеет разные варианты и не может быть разрешен
в один. Например, может быть несколько страниц index.html в зависимости от
на каком языке требуется (например, голландский).

Вернуться к началу

Код состояния HTTP — 301 перемещен навсегда

Запрошенному ресурсу был назначен новый постоянный URI и
любые будущие ссылки на этот ресурс должны использовать один из возвращенных
URI.

Вернуться к началу

Код состояния HTTP — 302 найдено

Запрошенный ресурс временно находится под другим URI.
Поскольку перенаправление может иногда изменяться, клиенту СЛЕДУЕТ
продолжать использовать Request-URI для будущих запросов.

Вернуться к началу

Код состояния HTTP — 304 Не изменено

Если клиент выполнил условный запрос GET и получил доступ
разрешено, но документ не был изменен, сервер ДОЛЖЕН
ответьте этим кодом состояния.Ответ 304 НЕ ДОЛЖЕН содержать тело сообщения,
и поэтому всегда заканчивается первой пустой строкой после заголовка
поля. Если клиент выполнил условный GET и доступ разрешен,
но документ не был изменен с указанной даты и времени
в поле If-Modified-Since сервер отвечает кодом состояния 304
и не отправляет тело документа клиенту. Заголовки ответа
как если бы клиент отправил запрос HEAD, но ограничивается только теми
заголовки, которые имеют смысл в данном контексте.Это означает только заголовки, которые
относятся к диспетчерам кеша и могут изменяться независимо
даты последнего изменения документа. Примеры включают дату, сервер
и истекает. Цель этой функции — обеспечить эффективное обновление
информации о локальном кэше (включая соответствующую метаинформацию) без
требуя накладных расходов на несколько HTTP-запросов (например, за HEAD следует
с помощью GET) и минимизация передачи уже известной информации
запрашивающим клиентом (обычно кеширующим прокси).

Вернуться к началу

Код состояния HTTP — временное перенаправление 307

Запрошенный ресурс временно находится под другим URI.
Поскольку перенаправление МОЖЕТ быть изменено при случае, клиенту СЛЕДУЕТ
продолжать использовать Request-URI для будущих запросов. Этот ответ
кэшируется только если указано в полях заголовка Cache-Control или Expires.

Вернуться к началу

Код состояния HTTP — 400 неверный запрос

Запрос не может быть понят сервером из-за неправильной формы.
синтаксис.Клиенту НЕ СЛЕДУЕТ повторять запрос без изменений.

Вернуться к началу

Код состояния HTTP — 401 Неавторизовано

Запрос требует аутентификации пользователя. Ответ ДОЛЖЕН содержать
поле заголовка WWW-Authenticate, содержащее запрос, применимый к
запрашиваемый ресурс.

Вернуться к началу

Код состояния HTTP — 403 Запрещено

Сервер понял запрос, но отказывается его выполнить.Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться.

Вернуться к началу

Код состояния HTTP — 404 не найдено

Сервер не нашел ничего, соответствующего Request-URI. Нет индикации
указывается, является ли состояние временным или постоянным.

Вернуться к началу

Код состояния HTTP — 410 ушел

Запрошенный ресурс больше не доступен на сервере и нет
адрес пересылки известен.Ожидается, что это условие будет учтено
постоянный. Клиенты с возможностью редактирования ссылок ДОЛЖНЫ удалять ссылки.
в Request-URI после утверждения пользователем.

Если сервер не знает или не имеет возможности определить,
или нет условие является постоянным, код состояния 404 не найден ДОЛЖЕН
использоваться вместо этого. Этот ответ кэшируется, если не указано иное.

Вернуться к началу

Код состояния HTTP — 500 Внутренняя ошибка сервера

Сервер обнаружил непредвиденное состояние, которое предотвратило его.
от выполнения запроса.

Вернуться к началу

Код состояния HTTP — 501 Не реализовано

Сервер не поддерживает функции, необходимые для выполнения
запрос. Это подходящий ответ, когда сервер не
распознает метод запроса и не может поддерживать его для
любой ресурс.

Вернуться к началу

Код состояния HTTP — 503 Служба недоступна

Ваш веб-сервер не может обработать ваш HTTP-запрос в данный момент.Существует множество причин, по которым это может происходить, но наиболее распространенные
являются:

• сбой сервера
• обслуживание серверов
• сервер перегрузка

Злонамеренная атака на сервер

• веб-сайт израсходовал выделенную полосу пропускания

Серверу

• может быть запрещено возвращать запрошенный документ

Обычно это временное состояние. Поскольку вы получаете возврат
код, часть сервера работает.Интернет-люди сделали сервер
возвращайте этот код, пока они не устранят проблему.

Если вы не получите обслуживание в ближайшее время, обратитесь к своему веб-хосту, как они
знаю лучше. У некоторых веб-хостов есть страницы состояния сервера, которые вы можете проверить.

К началу

Код состояния HTTP — 550 Permission Denied

Сервер указывает учетную запись, в которую вы сейчас вошли как
не имеет разрешения на выполнение действия, которое вы пытаетесь выполнить. Вы
может быть пытается загрузить в неправильный каталог или пытается удалить
файл.

Вернуться к началу

Ссылки W3C

1. W3C — 10 определений кодов состояния

2. W3C — 14 определений полей заголовка

Полный список кодов состояния HTTP + объяснение каждого

Что означает код состояния 2xx Succesful?

2xx Успешный код состояния означает, что запрос был успешным и браузер получил ожидаемую информацию. Обычно это тот, который вы хотите увидеть, поскольку это означает, что запрос был успешным, был получен, понят и принят.Как владелец веб-сайта вы должны убедиться, что все страницы и ресурсы (изображения, видео и т. Д.) Возвращают код состояния 2xx. Это означает, что браузеры могут успешно получить к нему доступ, и что посетители вашего сайта могут видеть и использовать ваш сайт.

Что означает 200 ОК?

Код состояния 200 OK означает, что запрос был успешным, но значение успеха зависит от используемого метода запроса:

• GET: запрошенный ресурс был получен и передан в тело сообщения.
• HEAD: поля заголовка из запрошенного ресурса отправляются без тела сообщения.
• POST или PUT: описание результата действия передается в тело сообщения.
• TRACE: сообщения запроса, полученные сервером, будут включены в тело сообщения

Если смотреть на вещи с точки зрения SEO, код ответа 200 OK — это идеальный код статуса для работающей страницы, все связанные страницы работают так, как должны. 200 будет означать, что сканеры поисковых систем могут успешно сканировать страницу, и она будет помещена в их поисковый индекс.

Что означает 201 Created?

Код состояния 201 Создано означает, что запрос был успешно выполнен и привел к созданию одного или, возможно, нескольких новых ресурсов.

Что означает 202 принято?

Код состояния 202 Accepted означает, что запрос был принят для обработки, но обработка еще не завершена. Запрос может или не может быть выполнен, когда в конечном итоге произойдет обработка.

Что означает 203 неавторизованная информация?

Код состояния 203 Non-Authoritative Information означает, что запрос был успешным. Однако полученная метаинформация отличается от метаинформации на исходном сервере и вместо этого была собрана из сторонней или локальной копии. Если он не используется для резервных копий или зеркал другого ресурса, предпочтительнее ответ 200 OK.

Что означает 204 Нет содержимого?

Код состояния 204 No Content означает, что, хотя сервер успешно выполнил запрос, доступного содержимого для этого запроса нет.Но пользовательский агент может захотеть обновить свои кэшированные в данный момент заголовки для этого ресурса для нового.

Что означает 205 Reset Content?

Код состояния 205 Reset Content означает, что пользователь должен сбросить документ, отправивший этот запрос.

Что означает 206 Частичное содержимое?

Код ответа 206 Partial Content — это ответ на заголовок Range, отправленный от клиента при запросе только части ресурса.

Что означает 207 Мульти-статус?

Код состояния 207 Multi-Status передает информацию о нескольких ресурсах в ситуации, когда подходят несколько кодов состояния.

Что означает 208 уже отправлено?

Код состояния 208 Already Reported используется внутри элемента ответа DAV: propstat , чтобы избежать повторного перечисления внутренних элементов нескольких привязок к одной и той же коллекции.

Что означает 226 IM Used?

Код 226 IM-ответа означает, что сервер успешно выполнил запрос GET для ресурса, а ответ является представлением результата одной или нескольких манипуляций с экземпляром, примененных к текущему экземпляру.