Реклама


500 Internal Server Error

Код состояния HTTP (англ. HTTP status code) — часть первой строки ответа сервера при запросах по протоколу HTTP. Он представляет собой целое трёхразрядное десятичное число. Первая цифра указывает на класс состояния. За кодом ответа обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

Клиент узнаёт по коду ответа о результатах своего запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Тем не менее известно о двух используемых кодах, не упомянутых в RFC: 449 Retry With. Также упоминается пояснительная фраза «Reply With»[1] в спецификации по WebDAV в Microsoft Developer Network, введённый Microsoft, и 509 Bandwidth Limit Exceeded, введённый в cPanel.

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

Веб-сервер Internet Information Services в своих файлах журналов, кроме стандартных кодов состояния, использует подкоды, записывая их через точку после основного. При этом в ответах от сервера данный подкод не размещается — он нужен администратору сервера, чтобы тот мог более точно определять источники проблем.

Обзорный список[ | код]

Ниже представлен обзорный список всех описанных в данной статье кодов ответа:

Диаграмма принятия веб-сервером решений на основе заголовков
Статистика по кодам ответа, сгенерированная анализатором логов Webalizer

Описание кодов[ | код]

Информационные[ | код]

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

Успех[ | код]

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

Перенаправление[ | код]

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

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

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

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

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

Ошибка клиента[ | код]

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

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

Ошибка сервера[ | код]

Пример ошибки 502 Bad Gateway

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

См. также[ | код]

Примечания[ | код]

  1. 1 2 2.2.6 449 «Retry With Status Code» // Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions. Архивная копия от 5 октября 2009 на Wayback Machine на сайте MSDN
  2. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 «6.1.1 Status Code and Reason Phrase Архивная копия от 7 июня 2018 на Wayback Machine» в RFC 2068
  3. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 RFC 2616. Дата обращения: 29 июля 2009. Архивировано 7 марта 2011 года.
  4. 1 2 3 IETF Draft WebDAV Advanced Collections Protocol — S.4.2.5. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  5. IETF Draft WebDAV Advanced Collections Protocol — S.10. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  6. rfc5842. Дата обращения: 12 сентября 2017. Архивировано 10 октября 2017 года.
  7. 1 2 3 4 5 6 7 8 9 10 RFC 2616 «10.3 Redirection 3xx» (стр. 61). Дата обращения: 29 июля 2009. Архивировано 7 марта 2011 года.
  8. rfc7538. Дата обращения: 12 сентября 2017. Архивировано 16 апреля 2015 года.
  9. IETF Draft WebDAV Advanced Collections Protocol — S.4.3.1.1. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  10. rfc7540. Дата обращения: 12 сентября 2017. Архивировано 23 июня 2015 года.
  11. 1 2 3 4 RFC 6585
  12. 1 2 IETF Draft A New HTTP Status Code to Report Legal Obstacles. Дата обращения: 6 марта 2013. Архивировано 22 мая 2013 года.
  13. RFC 2295 Transparent Content Negotiation in HTTP — S.8.1. Дата обращения: 18 мая 2012. Архивировано 8 июня 2012 года.
  14. IETF Draft WebDAV Advanced Collections Protocol — S.7.1. Дата обращения: 18 мая 2012. Архивировано 9 июля 2012 года.
  15. 1 2 3 4 5 6 7 Error Pages – CloudFlare Support. Дата обращения: 18 апреля 2016. Архивировано 4 марта 2016 года.
  16. RFC 2068 «10.3 Redirection 3xx» (стр. 56) Архивная копия от 7 июня 2018 на Wayback Machine.
  17. RFC 2616, раздел «10.3.3 302 Found», страница 63 Архивная копия от 7 марта 2011 на Wayback Machine.
  18. Josh Cohen HTTP/1.1 305 and 306 Response Codes Архивная копия от 8 сентября 2014 на Wayback Machine (англ.) // Netscape Communications Corp., 25 декабря 1996
  19. Что означает 403 Forbidden? Архивная копия от 21 февраля 2014 на Wayback Machine.
  20. Причины появления ошибки 404 Not Found Архивная копия от 21 февраля 2014 на Wayback Machine.
  21. RFC 2324 — Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0).
  22. draft-ietf-httpbis-legally-restricted-status-04. datatracker.ietf.org. Дата обращения: 22 декабря 2015. Архивировано 23 декабря 2015 года.
  23. Описание ошибки 500 Internal Server Error Архивная копия от 21 февраля 2014 на Wayback Machine.
  24. Resource Limit Reached. www.cloudlinux.com. Дата обращения: 21 июня 2022. Архивировано 15 мая 2021 года.

Ссылки[ | код]

Основные документы по протоколу HTTP (по убыванию даты публикации)
Документы по расширениям и обновлениям протокола HTTP (по убыванию даты публикации)
Дополнительные материалы
Реклама