Обзорная статья, которая даст базовые знания об HTTP/1.1
HTTP/1.1 — как старый, но надежный почтальон: иногда медлительный, зато проверенный временем. Да, у него нет супер способностей HTTP/2 или HTTP/3, но без него мы бы до сих пор кричали в веб-пустоту: "Эй, сервер, ты меня слышишь?!".
1. Что такое HTTP
HTTP (HyperText Transfer Protocol) — это протокол прикладного уровня, лежащий в основе передачи данных в вебе.
- Он использует модель "клиент-сервер": браузер или другая программа (клиент) обращается к серверу с запросом, а сервер отвечает соответствующими данными.
- HTTP/1.1 — одна из наиболее распространённых версий, обеспечивающая базовую функциональность: заголовки, методы, возможность использовать "виртуальные хосты" (через заголовок Host) и т. д.
Основные особенности:
- Запрос и ответ — это текстовые (строковые) сообщения с набором заголовков и опциональным телом.
- Статус-коды — в каждом ответе сервера содержится код, который даёт понять, что произошло с запросом (например, "200 OK", "404 Not Found").
- Заголовки — метаинформация, которая регулирует кэширование, тип данных, методы аутентификации, права доступа, сжатие и прочие аспекты.
Переходим к структуре.
2. Структура HTTP-запроса
2.1 Стартовая строка (Request Line)
В типичном запросе формата HTTP/1.1 есть первая строка вида:
METHOD Пример-Пути (path) HTTP/1.1
Например:
GET /users/42 HTTP/1.1
- METHOD — один из поддерживаемых методов (GET, POST, PUT, DELETE и пр.).
- Путь (path) — обычно начинается со /. Может включать query-параметры (?key=value).
HTTP/1.1 — версия протокола.
2.2 Заголовки (Headers)
После стартовой строки идёт набор заголовков. Каждый заголовок — это ключ-значение, разделённые двоеточием:
Host: example.com
User-Agent: curl/7.78.0
Accept: application/json
Content-Type: application/json
Authorization: Bearer ...
...
Ключевые заголовки, которые часто встречаются в заданиях:
- Host: обязательный в HTTP/1.1; указывает, к какому виртуальному хосту (домену) обращаемся.
- Content-Type: описывает тип передаваемого тела (например, application/json, text/html).
- Authorization: используется для передачи токенов, Basic Auth и т. д.
- Cookie: при повторных запросах браузер (или Postman) автоматически может подставлять куки.
- Set-Cookie (в ответе) — сервер задаёт куки клиенту.
2.3 Тело (Body)
Тело запроса не всегда есть.
- GET обычно без тела.
POST/ PUT/ PATCH часто передают данные (например, JSON):
{
"name": "Alice"
}
Важный момент: если отправляете JSON, указывайте заголовок Content-Type: application/json, чтобы сервер понял, как парсить данные.
3. Структура HTTP-ответа
3.1 Стартовая строка (Status Line)
HTTP/1.1 200 OK
- Версия протокола
- Числовой код состояния (200, 404 и т. д.)
- Текстовое описание (OK, Not Found и т. п.)
3.2 Заголовки ответа
Date: Wed, 25 May 2025 10:00:00 GMT
Content-Type: application/json
Content-Length: 123
Set-Cookie: SID=abc123; HttpOnly; Max-Age=1800
...
Некоторые важные заголовки:
- Content-Type: какой формат у тела ответа (JSON, HTML, файл и пр.).
- Content-Length или Transfer-Encoding: если сервер знает точный размер ответа, отправляет Content-Length. Если динамически формирует ответ, может использовать Transfer-Encoding: chunked.
- Set-Cookie: установка куки на клиентской стороне.
- Location: часто используется при редиректах (ответах типа 301, 302, 307).
3.3 Тело ответа
Может содержать HTML-страницу, JSON, бинарные данные (например, картинку) и т. д. При ошибках сервера тоже может быть тело с описанием ошибки.
4. Основные методы HTTP
Часто используемые:
- GET — получить ресурс (страницу, данные).
- POST — создать новый ресурс или выполнить какую-то операцию (например, авторизация).
- PUT — обновить ресурс (обычно в "идемпотентном" виде: повторный вызов приводит к тому же состоянию).
- DELETE — удалить ресурс.
- PATCH — частичное обновление (не всегда есть на практике).
"Идемпотентность" означает, что повторный запрос с теми же данными даёт тот же результат (без дублирования, ошибок и т. п.). GET, PUT и DELETE обычно считаются идемпотентными, POST — нет.
5. Коды состояния (Status Codes)
В протоколе HTTP заложено несколько сотен кодов, но на практике наиболее важные:
1xx (информационные)
- Почти не видны "извне", используются для внутренних механизмов, например "100 Continue".
2xx (успех)
- 200 OK: запрос успешен, вот ответ.
- 201 Created: успешно создан ресурс (часто в ответ на POST).
- 204 No Content: всё ок, но тело пустое.
3xx (редиректы)
- 301 Moved Permanently: ресурс переехал навсегда; клиент может кешировать редирект.
- 302 Found, 307 Temporary Redirect: временный редирект, разница в сохранении метода запроса. 307 сохраняет метод и тело, 302 исторически мог делать "что угодно".
- 303 See Other: часто используется для перенаправления на другую страницу после POST.
4xx (ошибка на стороне клиента)
- 400 Bad Request: запрос некорректен (например, не тот формат JSON, неправильные данные).
- 401 Unauthorized: нет аутентификации (нужен логин/токен). Часто требует "Bearer token" или Basic Auth.
- 403 Forbidden: аутентификация есть, но прав доступа нет.
- 404 Not Found: не найден ресурс.
- 405 Method Not Allowed: метод не поддерживается (сервер подсказывает Allow: GET, PUT, …).
5xx (ошибка на стороне сервера)
- 500 Internal Server Error: общая ошибка на сервере, часто возникает из-за неучтённых ситуаций (например, некорректные данные в базе).
- 502 Bad Gateway, 503 Service Unavailable: проблемы между прокси и приложением или само приложение недоступно.
- 504 Gateway Timeout: таймаут на стороне сервера.
6. Понятие "заголовки" и почему они важны
В HTTP заголовки отвечают почти за всё "неочевидное": кодировку, тип данных, кэширование, сжатиe, токены, куки, CORS-политику и пр.
6.1 Content-Type и Accept
- Content-Type: объясняет, в каком формате данное тело (JSON, HTML, XML и т. д.).
- Accept: что клиент "хочет" получить в ответ (например, application/json).
6.2 Authorization
- Самый простой вид: Authorization: Basic base64(login:password).
- Часто на практике: Authorization: Bearer <токен>.
6.3 Cookies
Клиент (браузер/ Postman) обычно автоматически подставляет куки во все следующие запросы к тому же домену/пути, если куки не истекли.
- Сервер выставляет куки через заголовок Set-Cookie: key=value; HttpOnly; Path=/; Max-Age=1800; Secure; SameSite=....
- В запросах клиента появляются Cookie: key=value.
6.4 CORS (Cross-Origin Resource Sharing)
- Когда фронтенд (JS в браузере) запрашивает данные с "чужого" домена, браузер проверяет заголовки Access-Control-Allow-Origin и другие.
- Если сервер не разрешил конкретный "origin", запрос блокируется.
- Важно: Postman или curl не ограничены правилами CORS, блокировка происходит только в браузерах.
7. Редиректы
При получении 3xx статуса и заголовка Location: <другой URL> клиент может:
- Автоматически перенаправиться (браузер так и делает).
- Инструменты типа curl требуют использовать флаг -L, чтобы следовать редиректу.
Разница между 301 (постоянный) и 302/307 (временный) в том, как кешировать и сохранять метод.
- 301 и 308 — "постоянные" редиректы.
- 302 и 307 — временные.
- 307 сохраняет исходный метод при перенаправлении, 302 исторически часто менял на GET.
8. Передача данных и сжатие: chunked, gzip
8.1 Chunked Transfer
- При передаче больших или неизвестных по размеру данных сервер может использовать Transfer-Encoding: chunked.
- Данные отправляются "кусками" (чанками): каждый кусок имеет собственный заголовок размера. Это удобно, когда ответ формируется "на лету".
8.2 Сжатие (Content-Encoding)
- Чтобы уменьшить трафик, сервер может сжимать ответ (gzip, deflate, br).
- Если сервер отправляет сжатое тело, он указывает Content-Encoding: gzip.
Браузер или Postman на лету распаковывают ответ (при условии, что есть в заголовках Accept-Encoding).
9. Практика аутентификации и разница 401/403
- 401 Unauthorized: означает "нужна аутентификация, но её нет или она неверна". Сервер может подсказать "WWW-Authenticate: Bearer realm=...".
- 403 Forbidden: "аутентификация есть, но прав недостаточно". Например, вы вошли под user, а нужен admin.
Во фронтенде часто путают эти коды и везде показывают "Не авторизован". Правильнее различать: "Войдите" (401) или "Недостаточно прав" (403).
10. Типовые примеры HTTP-запросов
10.1 Запрос в стиле curl
curl -v -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer admin" \
-d '{"name":"Alice"}' \
https://api.example.com/users
- -v — verbose-режим, показывает заголовки.
- -X POST — метод запроса.
- -H — добавляем заголовки.
- -d — тело запроса (данные).
10.2 GET с query-параметрами
curl -v "https://api.example.com/users?role=admin"
- После ? идут пары ключ=значение.
- Сервер может вернуть 200 со списком, или 404, если не нашёл.
11. Советы для успешной работы с API
- Сначала проверяем статус-код. Если 4xx — проблема в запросе клиента (форма, токен, путь). Если 5xx — серверная ошибка.
- Смотрим заголовки (особенно Content-Type, Allow, WWW-Authenticate, Authorization).
- Сравниваем с эталонным примером (например, что даёт /hello c 200). Если он работает, а новый запрос падает, значит что-то не так в заголовках/теле/пути/методе.
- Не забываем про Host в HTTP/1.1. Без него сервер может возвращать 400.
- При редиректах смотрим Location и статус (301/302/307). Учитываем, что curl требует флаг -L для следования.
- CORS — блокировка только внутри браузера. Postman и curl не подчиняются CORS.
- Cookies — не забывайте проверять, действительно ли Postman/браузер отправляет нужные cookie при последующих запросах.
- Content-Type — при POST/PUT с JSON обязательно ставьте application/json, иначе сервер может вернуть 400.
- 401 vs 403 — "нет токена или он неверен" vs "токен есть, но прав нет".
405 Method Not Allowed — заголовок Allow: GET, POST... подскажет, какие методы сервер принимает.
Теперь вы знаете, как браузер шепчет серверу свои желания (GET, POST) и как сервер отвечает (200 OK или грустный 404). А если захотите больше скорости — добро пожаловать в мир современных протоколов. Но про них — в другой раз!
P.S. Если эта статья загрузилась быстрее, чем страница в 1999 году — значит, HTTP/1.1 всё еще в строю.
Заходите в наш ТГ-канал, там все про API и архитектуру веб-сервисов (и не только):
t.me/openstudyit