Чтение HTTP-обмена построчно

Учимся читать сырой HTTP-обмен — то, что показывают DevTools и curl, — строка за строкой.

Уметь прочитать сырой запрос и ответ — базовый навык: именно это вы видите в DevTools (вкладка Network) и в выводе curl -v.

Анатомия запроса

Разберём типичный запрос на отправку формы:

POST /api/login HTTP/1.1          <- стартовая строка: метод, путь, версия
Host: app.example.com             <- какой хост (обязателен в HTTP/1.1)
Content-Type: application/json    <- формат тела
Content-Length: 38                <- размер тела в байтах
Authorization: Bearer eyJhbGci... <- токен авторизации
Accept: application/json          <- какой формат ответа хочу
                                  <- пустая строка отделяет заголовки от тела
{"email":"[email protected]","pass":"123"}  <- тело запроса (payload)

Ключевое: пустая строка обязательно разделяет заголовки и тело. Всё до неё — метаданные, всё после — полезная нагрузка.

Анатомия ответа

HTTP/1.1 200 OK                   <- статус-строка: версия, код, текст
Content-Type: application/json    <- формат тела ответа
Set-Cookie: session=abc; HttpOnly <- просьба сохранить cookie
Cache-Control: no-store           <- не кэшировать (это логин)
Content-Length: 51
                                  <- пустая строка
{"id":42,"name":"Анна","token":"eyJ..."}  <- тело ответа

Читаем сверху вниз: 200 OK — успех; application/json — придёт JSON; Set-Cookie — нас залогинили, браузер запомнит сессию; no-store — ответ не кэшируется.

Редирект на практике

Частый случай — перенаправление. Сервер отвечает 3xx и заголовком Location, куда идти дальше:

Запрос:
GET /old-page HTTP/1.1
Host: example.com

Ответ:
HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page    <- сюда браузер пойдёт автоматически

Браузер увидит 301 и сам сделает новый запрос на адрес из Location. В DevTools это видно как два запроса подряд.

Кэш и условные запросы

Чтобы не качать неизменившийся ресурс заново, используют условные запросы. Сервер при первой отдаче присылает «метку версии» ETag, а браузер при следующем запросе спрашивает: «отдай, только если изменилось»:

Первый ответ:
HTTP/1.1 200 OK
ETag: "v7-abc123"

Повторный запрос:
GET /style.css HTTP/1.1
If-None-Match: "v7-abc123"        <- "у меня версия v7-abc123"

Ответ, если не менялось:
HTTP/1.1 304 Not Modified         <- тело не передаётся, бери из кэша

Статус 304 Not Modified экономит трафик: тело не передаётся, браузер берёт ресурс из кэша. Это основа быстрой загрузки повторных визитов.

Чек-лист чтения обмена

  • Статус-код: 2xx/3xx/4xx/5xx — где проблема (или её нет).
  • Content-Type: что за формат тела пришёл.
  • Location: есть редирект?
  • Set-Cookie / Authorization: что с аутентификацией.
  • Cache-Control / ETag: кэшируется ли и как.

Итог

  • Запрос и ответ = стартовая строка + заголовки + пустая строка + тело.
  • Редирект — статус 3xx и заголовок Location.
  • Условные запросы (ETag/If-None-Match) дают 304 Not Modified и экономят трафик.
  • Этот навык напрямую применяется в DevTools и curl -v.
Проверьте себя
1. Что отделяет заголовки от тела в HTTP-сообщении?
AТочка с запятой
BПустая строка
CСлово BODY
DЗаголовок Content-Length
2. Какой заголовок указывает браузеру, куда перенаправиться при ответе 301?
AHost
BLocation
CReferer
DSet-Cookie
3. Что означает статус 304 Not Modified?
AРесурс удалён
BРесурс не изменился — бери из кэша, тело не передаётся
CОшибка сервера
DНужна авторизация
Поддержать проект