" title="Написать письмо">Написать письмо

Статистика

Пользователи : 1
Статьи : 1951
Просмотры материалов : 7075764
 
Ошибки интернета: 404, 403, 500, 503 и прочие (16.02.2011). Печать E-mail
2011 - Февраль
16.02.2011 21:25
Save & Share

Полный перечень сообщений от серверов браузеру, по стандарту реестра IANA.

 

Диаграмма принятия веб-сервером решений на основе заголовков.
Informational (Информационные).
100 Continue (Продолжать).
101 Switching Protocols (Переключение протоколов).
102 Processing (Идёт обработка).
2xx: Success (Успешно).
200 OK (Хорошо).
201 Created (Создано).
202 Accepted (Принято).
203 Non-Authoritative Information (Информация не авторитетна).
204 No Content (Нет содержимого).
205 Reset Content (Сбросить содержимое).
206 Partial Content (Частичное содержимое).
207 Multi-Status (Многостатусный).
226 IM Used (IM использовано).
3xx: Redirection (Перенаправление).
300 Multiple Choices (Множество выборов).
301 Moved Permanently (Перемещено окончательно).
302 Found (Найдено).
303 See Other (Смотреть другое).
304 Not Modified (Не изменялось).
305 Use Proxy (Использовать прокси).
306 (зарезервировано).
307 Temporary Redirect (Временное перенаправление).
4xx: Client Error (Ошибка клиента).
400 Bad Request (Плохой запрос).
401 Unauthorized (Не авторизован).
402 Payment Required (Необходима оплата).
403 Forbidden (Запрещено).
404 Not Found (Не найдено).
405 Method Not Allowed (Метод не поддерживается).
406 Not Acceptable (Не приемлемо).
407 Proxy Authentication Required (Необходима аутентификация прокси).
408 Request Timeout (Время ожидания истекло).
409 Conflict (Конфликт).
410 Gone (Удалён).
411 Length Required (Необходима длина).
412 Precondition Failed (Условие «ложно»).
413 Request Entity Too Large (Размер запроса слишком велик).
414 Request-URI Too Long (Запрашиваемый URI слишком длинный).
415 Unsupported Media Type (Неподдерживаемый тип данных).
416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим).
417 Expectation Failed (Ожидаемое не приемлемо).
418 I'm a teapot (Я - чайник).
422 Unprocessable Entity (Необрабатываемый экземпляр).
423 Locked (Заблокировано).
424 Failed Dependency (Невыполненная зависимость).
425 Unordered Collection (Неупорядоченный набор).
426 Upgrade Required (Необходимо обновление).
449 Retry With (Повторить с...).
5xx: Server Error (Ошибка сервера).
500 Internal Server Error (Внутренняя ошибка сервера).
501 Not Implemented (Не реализовано).
502 Bad Gateway (Плохой шлюз).
503 Service Unavailable (Сервис недоступен).
504 Gateway Timeout (Шлюз не отвечает).
505 HTTP Version Not Supported (Версия HTTP не поддерживается).
506 Variant Also Negotiates (Вариант тоже согласован).
507 Insufficient Storage (Переполнение хранилища).
509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала).
510 Not Extended (Не расширено).

Полное описание:

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). Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям (жарг. редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

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

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

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

Статус ответа Кеширование Если метод не GET или HEAD
301 Moved Permanently Можно как обычно. Спросить у пользователя подтверждения
и запросить другой ресурс исходным методом.
307 Temporary Redirect Можно только если указан заголовок
Cache-Control или Expires.
302 Found
303 See Other Никогда нельзя. Перейти автоматически, но уже методом GET.

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

301 Moved Permanently (Перемещено окончательно)
Появился в HTTP/1.0.
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Учтите что некоторые клиенты некорректно ведут себя при обработке данного кода (см. описание ко всему классу 3xx).

302 Found (Найдено)
Введено в HTTP/1.0.

Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Учтите что некоторые клиенты некорректно ведут себя при обработке данного кода (см. описание ко всему классу 3xx).

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

Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET (см. описание ко всему классу 3xx).

Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает 303 указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска[прим 2].

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 заголовка). Этот код был введён вместе с 303 вместо 302-ого для избежания неоднозначности (см. описание ко всему классу 3xx).

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

400 Bad Request (Плохой запрос)
Появился в HTTP/1.0.
Означает, что сервер обнаружил в запросе клиента синтаксическую ошибку.

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

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

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

Обратите внимание что этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Если не оплачена услуга хостинга сайта, то логичней возвращать клиенту ответ из класса 5xx. Например, как cPanel возвращает ответ 509 (Bandwidth Limit Exceeded) когда площадкой превышен лимит на потребление трафика.

403 Forbidden (Запрещено)
 
Сервер вернул ошибку 403 при попытке просмотра директории «cgi-bin», доступ к которой был запрещён.Появился в HTTP/1.0.
Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе со стороны клиента к указанному ресурсу.

Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 (или 407 для прокси). В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого ПО.

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

Наиболее вероятными причинами ограничения могут послужить:

Попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов.
Для доступа требуется аутентификация не средствами HTTP (например, для доступа к CMS или разделу для зарегистрированных пользователей).
Сервер не удовлетворён IP-адресом клиента (например, временная блокировка из-за частых обращений или же на этапе разработки приложения доступ разрешён только некоторым IP).
404 Not Found (Не найдено)
 
Некоторые разработчики оригинальны в уведомлении пользователей об ошибках. Перед вами сообщение об ошибке 404 на официальном сайте Белого Дома США (whitehouse.gov) в виде официального обращения. Это самая распространенная ошибка при пользовании Интернетом (основная причина - ошибка в написании адреса Web-страницы).

Появился в HTTP/1.0.
Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы.

405 Method Not Allowed (Метод не применим)
Появился в HTTP/1.1.
Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow разделив их запятой.

Обратите внимание что эту ошибку сервер должен возвращать если метод ему известен, но он не применим именно к указанному в запросе ресурсу. Если же указанный метод не применим на всём сервере, то клиенту нужно вернуть ответ 501 (Not Implemented).

406 Not Acceptable (Не приемлемо)
Появился в HTTP/1.1.
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса.

См. также управляемое клиентом согласование содержимого в статье по HTTP.
407 Proxy Authentication Required (Необходима авторизация прокси)
Появился в HTTP/1.1.
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере.

408 Request Timeout (Время ожидания истекло)
Появился в HTTP/1.1.
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время.

Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать (например, из-за повреждёния компакт-диска или потеря связи с другим компьютером в локальной сети). Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны чтобы дать возможность другим клиентам сделать запрос.

Разумеется, этот ответ не возвращается когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать не возможно.

409 Conflict (Конфликт)
Появился в HTTP/1.1.
Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.

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

411 Length Required (Необходима длина)
Появился в HTTP/1.1.
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI.

Такой ответ вполне естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку разрывая соединение когда клиент действительно пришлёт слишком объёмное сообщение.

412 Precondition Failed (Условие «ложно»)
Появился в HTTP/1.1.
Возвращается, если ни одно из условных полей заголовка запроса не было выполнено.

413 Request Entity Too Large (Размер запроса слишком велик)
Появился в HTTP/1.1.
Возвращается в случае, когда сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса клиентом.
Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос.

414 Request-URL Too Long (Запрашиваемый URL слишком длинный)
Появился в HTTP/1.1.
Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод 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 заголовка запроса.

418 I'm a teapot (Я - чайник)
Введено в 1998 году как традиционная первоапрельская шутка IETF, в RFC 2324, HTCPCP/1.0 (Протокол гипертекстового контроля кофейников). Не обязательно к реализации в существующих HTTP-серверах

Возвращается при попытке заварить кофе в чайнике.

422 Unprocessable Entity (Необрабатываемый экземпляр)
Введено в WebDAV.

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

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

Целевой ресурс из запроса заблокирован от применения к нему указанного метода.

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

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

425 Unordered Collection (Неупорядоченный набор)
Введено в черновике по WebDAV Advanced Collections Protocol.

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

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

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

449 Retry With (Повторить с...)
Введено корпорацией Microsoft для WebDAV.

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

В настоящий момент как минимум используется программой Microsoft Money. Более подробную информацию по данному коду ответа можно получить в библиотеке MSDN.

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

500 Internal Server Error (Внутренняя ошибка сервера)
Появился в HTTP/1.0.
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса 5xx.

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

Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим только к данному ресурсу, то нужно вернуть ответ 405 (Method Not Allowed).

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.

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

509 Bandwidth Limit Exceeded (Исчерпана пропускная ширина канала)
Введено в расширении bw/limited (mod_bwlimited) к Apache для cPanel.

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

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

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

Взято с https://ru.wikipedia.org/wiki/%D0%A1%D0%BF%D0%B8%D1%81%D0%BE%D0%BA_%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2_%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%B8%D1%8F_HTTP

Обновлено ( 13.05.2022 17:56 )
 
 

Последние новости


©2008-2024. All Rights Reserved. Разработчик - " title="Сергей Белов">Сергей Белов. Материалы сайта предоставляются по принципу "как есть". Автор не несет никакой ответственности и не гарантирует отсутствие неправильных сведений и ошибок. Вся ответственность за использование материалов лежит полностью на читателях. Размещение материалов данного сайта на иных сайтах запрещено без указания активной ссылки на данный сайт-первоисточник (ГК РФ: ст.1259 п.1 + ст.1274 п.1-3).

Много статей не имеет срока устаревания. Есть смысл смотреть и 2011, и даже 2008 год. Политика сайта: написать статью, а потом обновлять ее много лет.
Открыта карта ВТБ для донатов на дорогостоящие эксперименты: 5368 2902 0040 0838.

Рекламодателям! Перестаньте спамить мне на почту с предложениями о размещении рекламы на этом сайте. Я никогда спамером/рекламщиком не был и не буду!
Top.Mail.Ru