10 ЋписаниЯ кодов состоЯниЯ (Status Code Definitions).

Љаждый код состоЯниЯ, описанный ниже, включает описание метода (или методов), за которым он может следовать и метаинформации, требуемой в ответе.

10.1 1xx - €нформационные коды.

ќтот класс кодов состоЯниЯ указывает предварительный (временный) ответ, состоЯщий только из строки состоЯниЯ (Status-Line) и опциональных заголовков, и завершающийсЯ пустой строкой. ’ак как HTTP/1.0 не определЯл никаких 1xx кодов состоЯниЯ, серверы Ќ… „Ћ‹†Ќ› посылать 1xx ответы HTTP/1.0 клиентам, за исключением экспериментальных условий.

10.1.1 100 Џродолжать, Continue.

Љлиент может продолжать запрос. ќтот промежуточный ответ используетсЯ, длЯ того, чтобы сообщить клиенту, что начальнаЯ часть запроса была получена и еще не отвергнута сервером. Љлиенту ‘‹…„“…’ продолжить посылку оставшихсЯ данных запроса или, если запрос уже был выполнен, игнорировать этот ответ. ‘ервер „Ћ‹†…Ќ послать заключительный ответ после того, как запрос будет выполнен.

10.1.2 101 Џереключение протоколов, Switching Protocols.

‘ервер понимает и желает выполнить запрос клиента, если протокол прикладной программы в этом соединении будет изменен на тот, который указан в поле заголовка сообщениЯ Upgrade (раздел 14.41). ‘ервер переключит протокол на тот, который определен в поле заголовка ответа Upgrade непосредственно после пустой строки, котораЯ завершает ответ с кодом состоЯниЯ 101.

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

10.2 2xx - “спешные коды.

ќтот класс кодов состоЯниЯ указывает, что запрос клиента был успешно получен, понЯт, и принЯт.

10.2.1 200 OK.

‡апрос был удачно выполнен. €нформациЯ, возвращаемаЯ с ответом зависит от метода, используемого в запросе. Ќапример:

GET: в ответе представлен объект, соответствующий запрошенному ресурсу;
HEAD: в ответе представлены полЯ заголовка объекта (entity-header), соответствующие запрошенному ресурсу. ’ело сообщениЯ (message-body) отсутствует;
POST: в ответе представлено описание объекта или содержитсЯ результат действиЯ;
TRACE: в ответе представлен объект, содержащий сообщение запроса, полученого конечным сервером.

10.2.2 201 ‘оздан, Created.

‡апрос был выполнен и в результате был создан новый ресурс. Ќовый созданный ресурс может быть вызван по URI (одному или нескольким), возвращенным в объекте ответа; наиболее специфический URL длЯ ресурса отдаетсЯ в поле заголовка Location. Џервоначальный сервер „Ћ‹†…Ќ создать ресурс перед возвратом кода состоЯниЯ 201. …сли действие не может быть выполнено немедленно, сервер должен возвратить ответ с кодом состоЯниЯ 202 (ЏринЯто, Accepted) вместо 201.

10.2.3 202 ЏринЯто, Accepted.

‡апрос был принЯт длЯ обработки, но обработка не была завершена. ‚ конечном счете запрос ЊЋ†…’ быть, а ЊЋ†…’ и не быть выполнен, поскольку он ЊЋ†…’ быть отвергнут при фактической обработке. Ќе имеетсЯ никакой возможности вторичной посылки кода состоЯниЯ от асинхронной операции типа этой.

Ћтвет с кодом состоЯниЯ 202 преднамеренно уклончив. –ель его состоит в том, чтобы позволить серверу принЯть запрос длЯ некоторого другого процесса (возможно пакетно-ориентированного процесса, который выполнЯетсЯ только один раз в день) и не требовать при этом, чтобы соединение агента пользователЯ с сервером сохранЯлось до завершениЯ процесса. Ћбъекту, возвращенному с этим ответом ‘‹…„“…’ содержать индикатор текущего состоЯниЯ запроса и либо ссылку на монитор состоЯниЯ, либо некоторую оценку времени, когда пользователь может ожидать завершениЯ выполнениЯ запроса.

10.2.4 203 Ќе авторскаЯ информациЯ, Non-Authoritative Information.

‚озвращеннаЯ в заголовке объекта (entity-header) метаинформациЯ - это не оригинал, доступный на первоначальном сервере, а документ, собранный из локальных копий или копий третьей стороны. Џредставленный документ ЊЋ†…’ быть как подмножеством оригинальной версии, так и содержать сведениЯ, которые в ней не были представлены. Ќапример, включение локальной аннотирующей информацию о ресурсе ЊЋ†…’ расширить метаинформацию, известную первоначальному серверу. €спользование этого кода состоЯниЯ в ответе не ЯвлЯетсЯ необходимым, но может применЯтьсЯ тогда, когда код состоЯниЯ ответа отличен от 200 (OK).

10.2.5 204 Ќет содержимого, No Content.

‘ервер выполнил запрос, но нет никакой новой информации, которую можно послать обратно. …сли клиент - агент пользователЯ, ему Ќ… ‘‹…„“…’ изменЯть вид документа, который послужил причиной запроса. ќтот ответ предназначен прежде всего длЯ того, чтобы позволить вводить данные длЯ действий, не изменЯЯ вид активного документа агента пользователЯ. Ћтвет ЊЋ†…’ включать новую метаинформацию в форме заголовков объекта (entity-headers), которые ‘‹…„“…’ добавить к документу, показываемому в настоЯщее времЯ агентом пользователЯ.

Ћтвет с кодом состоЯниЯ 204 Ќ… „Ћ‹†…Ќ содержать тела сообщениЯ, и, таким образом, всегда завершаетсЯ первой пустой строкой после полей заголовка.

10.2.6 205 ‘бросить содержимое, Reset Content.

‘ервер выполнил запрос, и агенту пользователЯ ‘‹…„“…’ отменить просмотр документа, который инициировал запрос. ќтот ответ предназначен прежде всего длЯ того, чтобы позволить ввод данных, осуществлЯемый пользователем, с последующей очисткой формы, в которой сделан ввод, так, чтобы пользователь мог легко инициировать следующее действие ввода. Ћтвет Ќ… „Ћ‹†…Ќ содержать объект.

10.2.7 206 —астичное содержимое, Partial Content.

‘ервер выполнил частичный GET запрос ресурса. ‡апрос должен содержать поле заголовка Range (раздел 14.36), указывающее желаемый диапазон. Ћтвет „Ћ‹†…Ќ содержать либо поле заголовка Content-Range (раздел 14.17), указывающее диапазон, включенный в ответ, либо тип содержимого (Content-Type) должен быть равным "multipart/byteranges", а полЯ Content-Range должны содержатьсЯ в каждой части. …сли "multipart/byteranges" не используетсЯ, поле заголовка Content-Length в ответе „Ћ‹†ЌЋ соответствовать фактическому числу октетов (OCTETs), переданных в теле сообщениЯ (message-body).

Љэш, который не поддерживает заголовки Range и Content-Range Ќ… „Ћ‹†…Ќ кэшировать ответы с кодом состоЯниЯ 206.

10.3 3xx - Џеренаправление.

ќтот класс кодов состоЯниЯ указывает, что длЯ выполнениЯ запроса агенту пользователЯ необходимо придпринЯть дополнительное действие. ’ребуемое действие ЊЋ†…’ быть выполнено агентом пользователЯ без взаимодействиЯ с пользователем, тогда и только тогда, когда во втором запросе используетсЯ метод GET или HEAD. Ђгенту пользователЯ Ќ… ‘‹…„“…’ автоматически перенаправлЯть запрос более 5 раз, так как такие переадресации обычно указывают бесконечный цикл.

10.3.1 300 Њножественный выбор, Multiple Choices.

‡апрошенный ресурс имеет несколько представлений, и можно использовать любое из перечисленных. Љаждое представление имеет свое расположение и информацию длЯ агента по управлению диалогом (раздел 12), представленную таким образом, что пользователь (или агент пользователЯ) может выбрать наиболее подходЯщее представление и перенаправить запрос к нему.

…сли запрос был отличен от HEAD, то ответу ‘‹…„“…’ содержать объект, включающий список характеристик и адресов, из которого пользователь или агент пользователЯ может выбрать один наиболее подходЯщий. ”ормат объекта определЯетсЯ медиа типом, указанным в поле заголовка Content-Type. ‚ зависимости от формата и возможностей агента пользователЯ, выбор наиболее подходЯщего представлениЯ может выполнЯтьсЯ автоматически. Ћднако, эта спецификациЯ не определЯет какого-либо стандарта длЯ автоматического выбора.

…сли сервер имеет представление по умолчанию (наиболее предпочтительное), то ему ‘‹…„“…’ включить URL этого представлениЯ в поле Location; агенты пользователЯ ЊЋѓ“’ использовать значение полЯ Location длЯ автоматической переадресации. ќтот ответ ЯвлЯетсЯ кэшируемым, если не обозначено иного.

10.3.2 301 ЏостоЯнно перенесен, Moved Permanently.

‡апрошенному ресурсу был назначен новый постоЯнный URI, и любые будущие ссылки на этот ресурс ‘‹…„“…’ выполнЯть, используЯ один из возвращенных URI. Љлиентам с возможностЯми редактированиЯ свЯзей ‘‹…„“…’ автоматически переопределить ссылки на запрашиваемый URI (Request-URI), используЯ одну или несколько новых ссылок, возвращенных сервером в тех местах, где это возможно. ќтот ответ ЯвлЯетсЯ кэшируемым, если не обозначено иного.

…сли новый URI - это расположение, то ответу ‘‹…„“…’ содержать URL в поле Location. …сли метод запроса был не HEAD, то объекту ответа ‘‹…„“…’ содержать короткое гипертекстовое примечание с гиперссылкой на новый (или новые) URI.

…сли код состоЯниЯ 301 был получен в ответ на запрос, отличный от GET или HEAD, агент пользователЯ Ќ… „Ћ‹†…Ќ автоматически переназначать запрос, пока нет подтверждениЯ пользователЯ, так как иначе условиЯ запроса изменЯтсЯ.

Ћбратите внимание: Џри автоматическом переназначении запроса POST после получениЯ кода состоЯниЯ 301, некоторые существующие HTTP/1.0 агенты пользователЯ ошибочно изменЯт метод запроса на GET.

10.3.3 302 ‚ременно перемещен, Moved Temporarily.

‡апрошенный ресурс временно находитсЯ под другим URI. ’ак как переадресациЯ может быть изменена в любой момент, клиенту ‘‹…„“…’ продолжать использовать запрашиваемый URI (Request-URI) в будущих запросах. Љэшируемость этого ответа зависит только от содержимого полей заголовка Cache-Control или Expires (если этих полей нет, то ответ не кэшируетсЯ).

…сли код состоЯниЯ 302 был получен в ответ на запрос, отличный от GET или HEAD, агент пользователЯ Ќ… „Ћ‹†…Ќ автоматически переназначать запрос, пока нет подтверждениЯ пользователЯ, так как иначе условиЯ запроса изменЯтсЯ.

Ћбратите внимание: Џри автоматическом переназначении запроса POST после получениЯ кода состоЯниЯ 302, некоторые существующие HTTP/1.0 агенты пользователЯ ошибочно изменЯт метод запроса на GET.

10.3.4 303 ‘мотреть другой, See Other.

Ћтвет на запрос может быть найден под другим URI и его ‘‹…„“…’ запрашивать, используЯ метод GET длЯ этого ресурса. ќтот метод существует прежде всего длЯ того, чтобы производить вывод данных активизированного методом POST сценариЯ, используЯ перенаправление агента пользователЯ на указанный ресурс. Ќовый URI - это не ссылка, заменЯющаЯ первоначально запрошенный ресурс. Ћтвет с кодом состоЯниЯ 303 не кэшируем, но ответ на второй (переназначенный) запрос ЊЋ†…’ быть кэширован.

10.3.5 304 Ќе модифицирован, Not Modified.

…сли клиент выполнил условный GET запрос, и доступ разрешен, но документ не изменилсЯ, то серверу ‘‹…„“…’ ответить, используЯ этот код состоЯниЯ. Ћтвет Ќ… „Ћ‹†…Ќ содержать тела сообщениЯ.

Ћтвет „Ћ‹†…Ќ содержать следующие полЯ заголовка:

Date
ETag и/или Content-Location, если заголовок был бы послан в ответе с кодом состоЯниЯ 200 на этот же запрос
Expires, Cache-Control, и/или Vary, если значение полЯ (field-value) может отличатьсЯ от посланного в любом предыдущем ответе длЯ такого же варианта

…сли условный GET использует строгое сравнение кэша (strong cache validator) (смотреть раздел 13.3.3), ответу Ќ… ‘‹…„“…’ содержать других заголовков объекта (entity-headers). €наче (то есть, если условный GET использует слабое сравнение (weak validator)), ответ Ќ… „Ћ‹†…Ќ содержать других заголовков объекта; это предотвращает несогласованности между кэшированными телами объектов (entity-bodies) и модифицированными заголовками.

…сли ответ с кодом состоЯниЯ 304 указывает объект, в настоЯщее времЯ не кэшированный, то кэш „Ћ‹†…Ќ игнорировать ответ и повторить запрос без условного выражениЯ.

…сли кэш использует полученный ответ с кодом состоЯниЯ 304 длЯ модифицикации вхождениЯ кэша, кэш „Ћ‹†…Ќ модифицировать вхождение так, чтобы отразить любые новые значениЯ полей, данные в ответе.

Ћтвет с кодом состоЯниЯ 304 Ќ… „Ћ‹†…Ќ включать тела сообщениЯ (message-body), и, таким образом, всегда завершаетсЯ первой пустой строкой после полей заголовка.

10.3.6 305 €спользуйте прокси-сервер, Use Proxy.

Ћбращение к запрошенному ресурсу „Ћ‹†ЌЋ производитьсЯ через прокси-сервер, указанный в поле Location. ‚ поле Location указан URL прокси-сервера. ЋжидаетсЯ, что получатель повторит запрос через прокси-сервер.

10.4 4xx - Љоды ошибок клиента.

Љласс кодов состоЯниЯ 4xx предназначен длЯ случаев, когда клиент, возможно, допустил ошибку. ‡а исключением ответа на запрос HEAD, серверу ‘‹…„“…’ включить объект, содержащий объЯснение ошибочной ситуации, и объЯснение, ЯвлЯетсЯ ли она временной или постоЯнной. ќти коды состоЯниЯ применимы к любому методу запроса. Ђгентам пользователЯ ‘‹…„“…’ показывать пользователю любой включенный объект.

Ћбратите внимание: …сли клиент посылает данные, то реализации сервера, использующей TCP, следует гарантировать, что клиент подтвердил получение пакета(ов), содержащего ответ, прежде чем сервер закроет соединение. …сли клиент продолжает посылать данные серверу после закрытиЯ соединениЯ, TCP стек сервера пошлет пакет сброса (RST) клиенту, а TCP стек клиента, в свою очередь, может стереть клиентские неподтвержденные входные буфера прежде, чем они будут прочитаны и интерпретированы приложением HTTP.

10.4.1 400 €спорченный ‡апрос, Bad Request.

‡апрос не может быть понЯт сервером из-за malformed синтаксиса. Љлиенту Ќ… ‘‹…„“…’ повторЯть запрос без модификаций.

10.4.2 401 Ќесанкционированно, Unauthorized.

‡апрос требует установлениЯ подлинности пользователЯ. Ћтвет „Ћ‹†…Ќ включать поле заголовка WWW-Authenticate (раздел 14.46), содержащее вызов (challenge), применимый к запрошенному ресурсу. Љлиент ЊЋ†…’ повторить запрос с подходЯщим полем заголовка Authorization (раздел 14.8). …сли запрос уже включает рекомендации установлениЯ подлинности (Authorization credentials) в поле Authorization, то ответ с кодом состоЯниЯ 401 указывает, что в установлении подлинности этим рекомендациЯм отказано. …сли ответ с кодом состоЯниЯ 401 содержит тот же самый вызов, что и предшествующий ответ, а агент пользователЯ уже делал попытку установлениЯ подлинности по крайней мере один раз, то ‘‹…„“…’ показать пользователю объект, который был дан в ответе, так как этот объект ЊЋ†…’ включать relevant диагностическую информацию. “становление подлинности доступа в протоколе HTTP описываетсЯ в разделе 11.

10.4.3 402 ’ребуетсЯ оплата, Payment Required.

ќтот код зарезервирован длЯ будущего использованиЯ.

10.4.4 403 ‡апрещено, Forbidden.

‘ервер понЯл запрос, но отказываетсЯ выполнЯть его. “становление подлинности (Authorization) не поможет, и запрос Ќ… „Ћ‹†…Ќ быть повторен. …сли метод запроса не HEAD и сервер желает указать, почему запрос не был выполнен, ему ‘‹…„“…’ описать причину отказа в объекте. ќтот код состоЯниЯ обычно используетсЯ, когда сервер не желает указывать точную причину отказа, или когда никакой другой ответ не подходит.

10.4.5 404 Ќе найден, Not Found.

‘ервер не нашел ничего, соответствующего данному запрашиваемому URI (Request-URI). Ќикак не сообщаетсЯ ЯвлЯетсЯ ли такое положение временным или постоЯнным.

…сли сервер не желает делать данную информацию доступной клиенту, то вместо этого кода состоЯниЯ может использоватьсЯ код состоЯниЯ 403 (‡апрещено, Forbidden). Љод состоЯниЯ 410 (“дален, Gone) ‘‹…„“…’ использовать, если сервер знает через некоторый внутренне конфигурируемый механизм, что старый ресурс более недоступен, но не знает нового адреса длЯ пересылки.

10.4.6 405 Њетод не дозволен, Method Not Allowed.

Њетод, определенный в строке запроса (Request-Line) не дозволено применЯть длЯ ресурса, идентифицированного запрашиваемым URI (Request-URI). Ћтвет „Ћ‹†…Ќ включать заголовок Allow, содержащий список допустимых методов длЯ запрошенного ресурса.

10.4.7 406 Ќе приемлем, Not Acceptable.

ђесурс, идентифицируемый запросом, имеет возможности генерации только таких объектов ответа, которые имеют характеристики содержимого (content characteristics), не согласующиесЯ с заголовками приема (accept headers), представленными в запросе.

…сли это был не запрос HEAD, то в ответ ‘‹…„“…’ включить объект, содержащий список доступных характеристик объекта и адреса (locations), из которых пользователь или агент пользователЯ может выбрать наиболее подходЯщий. ”ормат объекта определеЯтсЯ медиа типом, представленным в поле заголовка Content-Type. ‚ зависимости от формата и возможностей агента пользователЯ, выбор наиболее подходЯщего варианта может выполнЯтьсЯ автоматически. Ћднако, эта спецификациЯ не определЯет никакого стандарта длЯ автоматического выбора.

Ћбратите внимание: HTTP/1.1 серверы позволЯют возвращать ответы, которые не приемлемы согласно заголовкам приема (accept headers), представленным в запросе. ‚ некоторых случаЯх, это может быть даже предпочтительно по сравнению с посылкой ответа с кодом состоЯниЯ 406. Ђгентам пользователЯ неплохо бы рассматривать заголовки поступившего ответа, чтобы определить, ЯвлЯетсЯ ли он приемлемым. …сли ответ недопустим, агенту пользователЯ ‘‹…„“…’ временно остановитьсЯ, чтобы получить больше данных и спросить пользователЯ о дальнейших действиЯх.

10.4.8 407 ’ребуетсЯ установление подлинности через прокси-сервер, Proxy Authentication Required.

ќтот код подобен коду 401 (Ќесанкционированно, Unauthorized), но указывает, что клиент „Ћ‹†…Ќ сначала установить свою подлинность (authenticate) прокси-серверу. Џрокси-сервер „Ћ‹†…Ќ возвратить поле заголовка Proxy-Authenticate (раздел 14.33), содержащее вызов (challenge), применЯемый прокси-сервером длЯ запрошенного ресурса. Љлиент ЊЋ†…’ повторить запрос с подходЯщим полем заголовка Proxy-Authorization (раздел 14.34). “становление подлинности доступа в протоколе HTTP описываетсЯ в разделе 11.

10.4.9 408 €стекло времЯ ожиданиЯ запроса, Request Timeout.

Љлиент не произвел запрос в течение времени, которое сервер готов ждать. Љлиент ЊЋ†…’ повторить запрос без модификаций позже.

10.4.10 409 Љонфликт, Conflict.

‡апрос не был выполнен из-за конфликта с текущим состоЯнием ресурса. ќтот код позволЯетсЯ только в ситуациЯх, когда ожидаетсЯ, что пользователь может решить конфликт и повторно передать запрос. ’елу ответа ‘‹…„“…’ содержать достаточное количество информации длЯ пользователЯ, чтобы он мог распознать источник конфликта. ‚ идеале, объект ответа должен включать достаточно информации длЯ пользователЯ или агента пользователЯ длЯ решениЯ проблемы; однако это может не быть возможно, да и не требуетсЯ.

Љонфликты, наиболее вероЯтно, будут возникать в ответ на запрос PUT. …сли используетсЯ версификациЯ, и объект, который должен быть помещен, включает изменениЯ ресурса, которые находЯтсЯ в противоречии со сделанными раньше каким-либо запросом (третьей стороны), сервер ЊЋ†…’ использовать ответ с кодом состоЯниЯ 409, чтобы показать, что он не может выполнить запрос. ‚ этом случае, объекту ответа ‘‹…„“…’ содержать список отличий двух версий в формате, определенном полем заголовка ответа Content-Type.

10.4.11 410 “дален, Gone.

‡апрошенный ресурс больше не доступен на сервере, и нет никакого адреса длЯ перенаправлениЯ запроса. ’акое состоЯние ‘‹…„“…’ рассматривать как постоЯнное. Љлиентам с возможностЯми редактированиЯ гиперсвЯзей ‘‹…„“…’ удалить ссылки на запрашиваемый URI (Request-URI) после одобрениЯ пользователем. …сли сервер не знает, или не может определить, ЯвлЯетсЯ ли такое положение постоЯнным или нет, то ему ‘‹…„“…’ вместо этого кода использовать код состоЯниЯ 404 (Ќе найден, Not Found). ќтот ответ ЯвлЯетсЯ кэшируемым, если не обозначено иного.

Ћтвет с кодом состоЯниЯ 410 предназначен прежде всего длЯ того, чтобы помочь в сопровождении WWW, уведомлЯЯ получателЯ, что ресурс преднамеренно недоступен и что владельцы сервера желают, чтобы удаленные свЯзи, указывающие на этот ресурс были удалены. ’акое случаетсЯ в основном длЯ ограниченных по времени, рекламных сервисов и длЯ ресурсов, принадлежащих личностЯм, больше не занимающимсЯ сайтом. Ќе обЯзательно отмечать все постоЯнно недоступные ресурсы как "удаленные" ("gone") или хранить запись в течение любого отрезка времени - это предоставлЯетсЯ на усмотрение владельца сервера.

10.4.12 411 ’ребуетсЯ длина, Length Required.

‘ервер отказываетсЯ принимать запрос с неопределенным Content-Length. Љлиент ЊЋ†…’ повторить запрос, если добавит допустимое поле заголовка Content-Length, содержащее длину тела сообщениЯ (message-body) в сообщении запроса.

10.4.13 412 Џредусловие неверно, Precondition Failed.

Џредусловие, представленное одним или несколькими полЯми заголовка запроса (request-header), оказалось ложным при проверке сервером. ќтот код ответа позволЯет клиенту поместить предусловиЯ на текущую метаинформацию ресурса (данные полей заголовка) и, таким образом, предотвратить применение запрошенного метода к ресурсу, отличному от того, длЯ которого предназначен метод.

10.4.14 413 Ћбъект запроса слишком большой, Request Entity Too Large.

‘ервер отказываетсЯ обрабатывать запрос, потому что объект запроса больше, чем сервер желает или способен обработать. ‘ервер может закрыть соединение, чтобы не дать клиенту возможность продолжить запрос.

…сли это временное состоЯние, то серверу ‘‹…„“…’ включить поле заголовка Retry-After длЯ указаниЯ времени, через которое клиент может снова повторить запрос.

10.4.15 414 URI запроса слишком длинный, Request-URI Too Long.

‘ервер отказываетсЯ обслуживать запрос, потому что запрашиваемый URI (Request-URI) длиннее, чем сервер желает интерпретировать. ќто редкое состоЯние, которое, по всей вероЯтности, происходит только тогда, когда клиент неправильно преобразовал запрос POST к запросу GET с длинной информацией запроса, либо когда клиент попал в "черную дыру" URL перенаправлениЯ (например, перенаправленный URL префикс указывает на свой суффикс), или когда на сервер производитсЯ нападение клиентом, пытающимсЯ эксплуатировать лазейки в секретности, имеющиесЯ в некоторых серверах, использующих буфера фиксированной длины длЯ чтениЯ или манипулированиЯ с запрашиваемым URI (Request-URI).

10.4.16 415 Ќеподдерживаемый медиа тип, Unsupported Media Type.

‘ервер отказываетсЯ обслуживать запрос, потому что объект запроса находитсЯ в формате, не поддерживаемом запрошенным ресурсом длЯ запрошенного метода.

10.5 5xx - Љоды ошибок сервера.

Љоды состоЯниЯ, начинающиесЯ с цифры "5" указывают случаи, в которых сервер знает, что допустил ошибку или неспособен выполнить запрос. ЋтвечаЯ на запрос, за исключением запроса HEAD, серверу ‘‹…„“…’ включить объект, содержащий объЯснение ошибочной ситуации и информацию, ЯвлЯетсЯ ли это положение временным или постоЯнным. Ђгентам пользователЯ ‘‹…„“…’ показывать пользователю любой включенный объект. ќти коды состоЯниЯ применимы к любому методу запроса.

10.5.1 500 ‚нутреннЯЯ ошибка сервера, Internal Server Error.

‘ервер столкнулсЯ с непредвиденным условием, которое не позволЯет ему выполнить запрос.

10.5.2 501 Ќе реализовано, Not Implemented.

‘ервер не поддерживает функциональные возможности, требуемые длЯ выполнениЯ запроса. ќтот ответ соответствует состоЯнию, когда сервер не распознает метод запроса и не способен обеспечитиь его длЯ любого ресурса.

10.5.3 502 Ћшибка шлюза, Bad Gateway.

‘ервер, действуЯ в качестве шлюза или прокси-сервера, получил недопустимый ответ от следующего сервера в цепочке запросов, к которому обратилсЯ при попытке выполнить запрос.

10.5.4 503 ‘ервис недоступен, Service Unavailable.

‘ервер в настоЯщее времЯ не способен обработать запрос из-за временной перегрузки или обслуживаниЯ сервера. ќто временное условие, которое будет облегчено после некоторой задержки. …сли известна продолжительность задержки, она может быть указана в заголовке Retry-After. …сли Retry-After не присутствует в ответе, клиенту ‘‹…„“…’ обрабатывать этот ответ как ответ с кодом 500.

Ћбратите внимание: существование кода состоЯниЯ 503 не подразумевает, что сервер должен использовать его, когда перегружен. Ќекоторые сервера могут просто закрывать соединение.

10.5.5 504 €стекло времЯ ожиданиЯ от шлюза, Gateway Timeout.

‘ервер, действуЯ в качестве шлюза или прокси-сервера, не получил своевременного ответа от следующего сервера в цепочке запросов, к которому обратилсЯ при попытке выполнить запрос.

10.5.6 505 Ќе поддерживаемаЯ версиЯ HTTP, HTTP Version Not Supported.

‘ервер не поддерживает, или отказываетсЯ поддерживать, версию HTTP протокола, котораЯ используетсЯ в сообщении запроса. ‘ервер указывает, что не способен или не желает выполнЯть запрос, используЯ ту же самую major версию, что и клиент, как описано в разделе 3.1, в других сообщениЯх. Ћтвету ‘‹…„“…’ содержать объект, описывающий, почему эта версиЯ не поддерживаетсЯ, и какие другие протоколы поддерживаютсЯ этим сервером.