Курсы английского языка курсы турецкого языка Курсы китайского языка Курсы французского языкакитайский язык курсытурецкий язык Список кодов состояния HTTP
СПб ТЕЛЕКОМ
Корзина  
Сумма: 0.00 руб.
Количество: 0 шт.
e-mail: sales@spbtelecom.ru

ICQ: 436502388
Главная Товары Услуги Как купить Поддержка Карта сайта
СЕРВЕР
ПРОФЕССИОНАЛОВ
В ОБЛАСТИ СВЯЗИ
Имя  Пароль 
Регистрация 
ПОИСК
Список кодов состояния HTTP
 
Поддержка / Словарь терминов / Прочее / Список кодов состояния HTTP
Код состояния HTTP (англ. HTTP status code) — код состояния является частью первой строки ответа сервера. Он представляет из себя целое число из трех арабских цифр. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа.
Пример:
403 Access allowed only for registered users

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и все они описаны в соответствующих документах RFC. Введение новых кодов должно производится только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.
В настоящее время выделено пять классов кодов состояния:
    * 1xx: Informational (русск. Информационный) — запрос получен и понят, а обработка продолжается.
    * 2xx: Success (русск. Успешно) — запрос был успешно получен, понят и обработан.
    * 3xx: Redirection (русск. Перенаправление) — для выполнения запроса должны быть предприняты дальнейшие действия.
    * 4xx: Client Error (русск. Ошибка клиента) — запрос имеет плохой синтаксис или не может быть выполнен.
    * 5xx: Server Error (русск. Ошибка сервера) — сервер не в состоянии выполнить допустимый запрос.

Ниже представлены коды ответа из реестра кодов состояния IANA.


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

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

101
Switching Protocols (русск. Переключение протоколов)
Появился в HTTP/1.1.
Сервер предлагает перейти на более подходящий для указанного ресурса протокол. Список предлагаемых протоколов сервер обязательно указывает в поле заголовка Update. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола.

102
Processing русск. Идёт обработка
Появился в WebDAV.
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме.


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

200
OK (русск. Хорошо)
Появился в HTTP/1.0.
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения.

201
Created (русск. Создано)
Появился в HTTP/1.0.
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ 202.

202
Accepted (русск. Принято)
Появился в HTTP/1.0.
Запрос был принят на обработку, но обработка не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс.

203
Non-Authoritative Information (русск. Неавторитетная информация)
Появился в HTTP/1.1.
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной.

204
No Content (русск. Нет содержимого)
Появился в HTTP/1.0.
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные.

205
Reset Content (русск. Сбросить содержимое)
Появился в HTTP/1.1.
Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно.

206
Partial Content (русск. Частичное содержимое)
Появился в HTTP/1.1.
Сервер удачно выполнил частичный GET. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию.

207
Multi-Status (русск. Многостатусный)
Появился в WebDAV.
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с единственным объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности.

226
IM Used (русск. IM использовано)
Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров.


3xx: Redirection
Коды статуса класса 3xx сообщают клиенту что для успешного выполнения операции нужно произвести следующий запрос к другому URI. В большинстве случаев новый адрес указывается в поле Location заголовка. Клиент в этом случае должен, как правило, произвести автоматический переход (жарг. редирект).
Обратите внимание, что при обращении к следующему ресурсу можно получить ответ из этого же класса кодов. Может получиться даже длинная цепочка из перенаправлений, которые, если будут производится автоматически, создадут чрезмерную нагрузку на оборудование. Поэтому разработчики протокола HTTP настоятельно рекомендуют после второго подряд подобного ответа обязательно запрашивать подтверждение на перенаправление у пользователя (раньше рекомендовалось после 5-го). За этим следить обязан клиент, так как текущий сервер может перенаправить клиента на ресурс другого сервера. Клиент также должен предотвратить попадание в круговые перенаправления.

300
Multiple Choices (русск. Несколько выборов)
Появился в HTTP/1.0.
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту или пользователю.

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

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

303
See Other (русск. Смотреть другое)
Введено в HTTP/1.1.
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET не смотря даже на то, что первый запрашивался методом POST. Если используется не метод HEAD, то серверу следует включить в тело сообщения короткое гипертекстовое описание.

304
Not Modified (русск. Не изменено)
Появился в HTTP/1.0.
Сервер возвращает такой код, если клиент запросил документ методом GET, в заголовке использовал поле Date и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела.

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
Bad Request (русск. Плохой запрос)
Появился в HTTP/1.0.
Запрос не понят сервером из-за наличия синтаксической ошибки. Клиенту следует повторно обратиться к ресурсу с изменённым запросом.

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

402
Payment Required (русск. Необходима оплата )
Зарезервировано. Появился в HTTP/1.1.
Предполагается использовать в будущем. В настоящий момент не используется.

403
Forbidden (русск. Запрещено)
Появился в HTTP/1.0.
Сервер понял запрос, но он отказывается его выполнять из-за каких-то ограничений в доступе. Идентификация через протокол HTTP здесь не поможет. Скорее всего, на сервере нужно провести аутентификацию другим способом, сделать запрос с определёнными параметрами или удовлетворить каким-либо условиям.

404
Not Found (русск. Не найдено)
Появился в HTTP/1.0.
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 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 (русск. Необрабатываемый экзмепляр)
Введено в WebDAV.
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка из-за которой невозможно произвести операцию над ресурсом.

423
Locked (русск. Заблокировано)
Введено в WebDAV
Целевой ресурс из запроса заблокирован от применения к нему указанного метода.

424
Failed Dependency (русск. Невыполненная зависимость)
Введено в WebDAV.
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт код 424.

426
Upgrade Required (русск. Необходимо обновление)
Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля 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 (русск. Закончилось место)
Введено в WebDAV.
Не хватает места для выполнения текущего запроса. Проблема может быть временной.

510
Not Extended (русск. Не расширено)
Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
На сервере отсутствует расширение, которое планирует использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях.