Протокол HTTP
2026-02-26 15:09 Diff
https://ru.hexlet.io/courses/http_protocol/lessons/body/theory_unit

В этом уроке мы рассмотрим, как с помощью HTTP-запросов и ответов передаются данные и из чего состоит HTTP-сообщение. Мы изучим, как правильно формировать и обрабатывать данные, отправляемые в теле запроса, а также как серверы обрабатывают эти данные в ответах.

Структура HTTP

HTTP request и response могут содержать так называемое тело (body). Тело используется для передачи данных от клиента к серверу и наоборот. Например, отправка формы на странице, при регистрации, создание заказа и так далее. Сервер в теле ответа может вернуть HTML-страницу, картинку или JSON.

Мы уже знаем, что сам HTTP-запрос состоит из заголовков и опционального тела запроса. Для отделения заголовков от тела существуют определенные правила. Давайте посмотрим на примере, как работать с body и каким образом посылать какие-то данные кроме заголовков. Сделаем HTTP-запрос к хосту http.hexlet.app:

Ответ:

В ответ мы получаем какие-то заголовки и далее идет тело, которое нас как раз и интересует. В данном случае это список задач.

Если с заголовками все понятно, они отделяются друг от друга переводом строки и для отправки мы добавляем еще один перевод, который выглядит как пустая строка, то как быть с телом запроса? Оно может содержать внутри все что угодно. Мы не можем кодировать перевод строки как специальный символ. Ведь те самые два перевода строки могут находиться внутри тела запроса. Но существуют и другие причины, по которым в текстовом протоколе нельзя просто так определить когда заканчивается тело. Если бы мы приняли ответ при отсутствии каких-то специальных механизмов, то после того как сервер отправил первые два перевода строки мы сразу увидели бы ответ и все что посылалось дальше вообще не считалось бы частью ответа HTTP response. Для решения этой проблемы был придуман другой, более универсальный механизм. Он основан на передаче специального заголовка.

Во время отправки ответа сервер формирует специальный заголовок, который называется Content-Length. Это и есть ключ к тому как работать с body. Перед тем как отправить тело ответа, происходит вычисление его длины и записывается количество байт.

После того как передан такой заголовок, другая сторона будет ожидать ровно столько байт, сколько в нем указано. Как мы помним, для response и request это работает абсолютно одинаково. После того как был передан последний символ, запрос считается завершенным. Соединение может быть закрыто, но при keep-alive оно остается открытым для следующих запросов.

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

Практика показывает, что не все серверы правильно работают при наличии только заголовка Content-Length. Им не хватает еще одного. Тип содержимого запроса или ответа, которое содержит body, должен быть как-то идентифицирован. По умолчанию в стандарте сказано, что сервер может сам попытаться определить содержимое контента на основе различных способов. Например, мы в query string делаем запрос tasks.

Совсем не обязательно, но сервер может понять, что это JSON, и как-то это использовать. Во всех остальных случаях, когда сервер не может определить тип контента, он должен использовать заголовок Content-Type: application/octet-stream. Это означает, что в теле запроса передается просто поток байтов. Хотя серверы должны работать именно так, но часто все происходит по-другому. Если указан только Content-Length, то сервер отказывается принимать данные. Он просто закрывает соединение после двух переводов строки, еще до body. Этот нюанс выяснен экспериментальным путем.

Еще одно замечание по поводу body. С точки зрения стандарта HTTP тело может присутствовать в любом запросе и никак не связано с глаголом. Посылать body можно в HEAD, POST, PUT и других запросах. Если мы посылаем body с GET, хотя это не описано в стандарте, сервер никак не будет на это реагировать, более того, он и не должен, так как с практической точки зрения это не имеет смысла. Также есть типы запросов, при которых он не будет посылать в ответ body ни в коем случае. Например, ответ на HEAD, когда мы запрашиваем только заголовки, так как такова семантика этого глагола. Еще тело не отправляется, когда мы получаем в ответ такие статусы как 204 — нет контента и некоторые другие.

Выводы

  1. Структура HTTP-запроса и ответа: HTTP-запросы и ответы состоят из заголовков и опционального тела. Заголовки отделяются друг от друга переводами строки, а тело запроса или ответа следует после пустой строки.
  2. Передача данных в теле запроса: Тело запроса может содержать любые данные, и его длина указывается с помощью заголовка Content-Length. Это позволяет серверу и клиенту точно знать, сколько байт данных ожидается.
  3. Заголовок Content-Type: Для корректной обработки данных в теле запроса или ответа необходимо указывать заголовок Content-Type, который определяет тип содержимого. Если тип не может быть определен, используется значение application/octet-stream.
  4. Работа с телом в различных запросах: Тело может присутствовать в различных типах запросов (например, POST, PUT), но не имеет смысла в GET-запросах. Некоторые запросы, такие как HEAD, не возвращают тело в ответе.
  5. Проблемы с обработкой запросов: Некоторые серверы могут некорректно обрабатывать запросы, если указан только заголовок Content-Length, без указания Content-Type. Это может привести к закрытию соединения до получения тела запроса.
  6. Завершение HTTP-сессии: После передачи тела ответа соединение может быть закрыто, но это не обязательно означает завершение работы сервера, если используется механизм keep-alive.