HTTP
HTTP-ответы

параметры

Основной формат ответа

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

HTTP/1.1 200 OK \r\n

HTTP/1.1 404 Not Found \r\n

HTTP/1.1 503 Service Unavailable \r\n

Простой ответ HTTP 1.1 имеет такой формат:

HTTP-Version Status-Code Reason-Phrase CRLF

Как и в запросе, HTTP-Version указывает версию используемого протокола HTTP; для HTTP 1.1 это всегда должно быть строка HTTP/1.1 .

Status-Code - это трехзначный код, который указывает статус запроса клиента. Первая цифра этого кода - это класс статуса , который помещает код состояния в одну из 5 категорий ответа ^[1] :

• 1xx Информационный - сервер получил запрос и обработка продолжается
• 2xx Success - сервер принял и обработал запрос
• 3xx Redirection - требуется дальнейшие действия со стороны клиента для завершения запроса
• Ошибки клиента 4xx - клиент отправил запрос, который был искажен или не может быть выполнен
• Ошибки сервера 5xx - запрос был действительным, но сервер не может выполнить его в настоящее время

Reason-Phrase - это краткое описание кода состояния. Например, код 200 имеет причину фразы OK ; код 404 имеет фразу « Not Found . Полный список фраз причины доступен в параметрах, ниже или в спецификации HTTP .

Линия заканчивается парой обратной линии возврата каретки, обычно представленной \r\n .

Дополнительные заголовки

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

Полный список доступных заголовков определен в разделе 6.2 спецификации . Наиболее часто используемые заголовки:

• Server , который функционирует как заголовок запроса User-Agent для сервера;
• Location , которое используется для ответов статуса 201 и 3xx, чтобы указать URI для перенаправления; а также
• ETag , который является уникальным идентификатором для этой версии возвращаемого ресурса, чтобы клиенты могли кэшировать ответ.

Заголовки ответов поступают после строки состояния, и поскольку заголовки запросов формируются как таковые:

Name: Value CRLF

Name содержит имя заголовка, например ETag или Location , а Value - значение, заданное сервером для этого заголовка. Линия заканчивается CRLF.

Ответ с заголовками может выглядеть так:

HTTP/1.1 201 Created \r\n
Server: WEBrick/1.3.1 \r\n
Location: http://example.com/files/129742 \r\n

Органы сообщения

Как и в структурах запросов , HTTP-ответы могут содержать тело сообщения. Это предоставляет дополнительные данные, которые клиент будет обрабатывать. Примечательно, что ответы 200 OK на хорошо сформированный запрос GET должны всегда предоставлять тело сообщения, содержащее запрошенные данные. (Если их нет, 204 No Content - более подходящий ответ).

Тело сообщения включено после всех заголовков и двойной CRLF. Что касается запросов, то его длина в байтах должна быть задана заголовком Content-Length . Следовательно, успешный ответ на запрос GET может выглядеть так:

HTTP/1.1 200 OK\r\n
Server: WEBrick/1.3.1\r\n
Content-Length: 39\r\n
ETag: 4f7e2ed02b836f60716a7a3227e2b5bda7ee12c53be282a5459d7851c2b4fdfd\r\n
\r\n
Nobody expects the Spanish Inquisition.