HTTP-запросы

HTTP-запрос — это сообщение, отправляемое клиентом (например, веб-браузером, мобильным приложением или серверным ботом) на сервер по протоколу передачи гипертекста (HTTP) с целью получения или отправки данных. HTTP-запрос является основным элементом взаимодействия в архитектуре «клиент-сервер», лежащей в основе работы Всемирной паутины (World Wide Web) и большинства современных веб-приложений. Каждый запрос состоит из стартовой строки, заголовков и, опционально, тела сообщения.

Структура HTTP-запроса

HTTP-запрос имеет строго определённый текстовый формат, регламентированный стандартами RFC 7230 и последующими спецификациями. Он состоит из трёх основных частей.

Стартовая строка

Стартовая строка (request line) содержит три обязательных элемента, разделённых пробелами:

1. Метод HTTP (глагол, указывающий на действие, например, GET, POST, PUT, DELETE).
2. URI (Uniform Resource Identifier) — путь к запрашиваемому ресурсу на сервере (например, /index.html или /api/users?id=123). В HTTP/1.1 обычно указывается абсолютный путь, а в HTTP/1.0 — полный URL.
3. Версия протокола (например, HTTP/1.1 или HTTP/2).

Пример: GET /index.html HTTP/1.1

Заголовки запроса

Заголовки (headers) представляют собой набор строк в формате «Ключ: Значение», которые передают метаданные о запросе, клиенте и ожидаемом ответе. Заголовки завершаются пустой строкой, отделяющей их от тела запроса. Основные типы заголовков:

• Общие заголовки (general headers): применимы как к запросу, так и к ответу (например, Date, Cache-Control).
• Заголовки запроса (request headers): содержат информацию о клиенте и предпочтениях (например, User-Agent, Accept, Referer, Authorization).
• Заголовки сущности (entity headers): описывают тело запроса (например, Content-Type, Content-Length).

Примеры заголовков: `` Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Accept: text/html,application/xhtml+xml Content-Type: application/json ``

Тело запроса

Тело (body) — это необязательная часть, которая содержит данные, передаваемые серверу. Оно присутствует в запросах, изменяющих состояние сервера (например, POST, PUT, PATCH). Тело может быть в любом формате, но чаще всего используется JSON, XML, URL-кодированные данные формы (application/x-www-form-urlencoded) или бинарные данные (например, изображения). Формат тела указывается в заголовке Content-Type, а размер — в Content-Length.

Методы HTTP-запросов

Метод HTTP-запроса (или HTTP-глагол) определяет предполагаемое действие с ресурсом. Стандарт HTTP/1.1 определяет несколько основных методов, а также расширения (например, PATCH).

GET

Метод GET используется для запроса данных с сервера. Он не должен изменять состояние сервера (идемпотентен) и не имеет тела запроса. Ответ может кэшироваться. GET-запросы часто содержат параметры в строке URI (например, ?id=1&page=2).

POST

Метод POST предназначен для отправки данных на сервер для создания нового ресурса или выполнения действия. Тело запроса обязательно. POST-запросы не являются идемпотентными — повторная отправка может привести к созданию нескольких ресурсов.

PUT

Метод PUT заменяет текущее представление ресурса данными, переданными в теле запроса. Если ресурс не существует, он может быть создан. PUT является идемпотентным — повторный запрос с теми же данными не изменит состояние сервера.

DELETE

Метод DELETE удаляет указанный ресурс. Он также является идемпотентным — после первого удаления последующие запросы вернут тот же результат (чаще всего код 404 или 410).

PATCH

Метод PATCH применяется для частичного изменения ресурса. В отличие от PUT, он не заменяет весь ресурс, а модифицирует его. PATCH не обязательно является идемпотентным.

Другие методы

• HEAD — аналогичен GET, но сервер возвращает только заголовки ответа без тела. Используется для проверки существования ресурса или получения метаданных.
• OPTIONS — запрашивает информацию о доступных методах и опциях для указанного ресурса. Сервер возвращает заголовок Allow.
• CONNECT — устанавливает туннель к серверу через прокси (часто используется для HTTPS-соединений).
• TRACE — выполняет диагностический запрос для проверки пути прохождения запроса через промежуточные серверы.

Классификация HTTP-запросов

HTTP-запросы можно классифицировать по нескольким критериям.

По версии протокола

• HTTP/0.9 (1991) — простейшая версия, поддерживающая только метод GET без заголовков.
• HTTP/1.0 (1996) — добавил заголовки, методы POST и HEAD, но каждое соединение закрывалось после одного запроса.
• HTTP/1.1 (1997) — стандартная версия, поддерживающая постоянные соединения (keep-alive), конвейерную обработку (pipelining), виртуальные хосты и множество методов.
• HTTP/2 (2015) — бинарный протокол, поддерживающий мультиплексирование (несколько запросов в одном соединении), сжатие заголовков и серверный push.
• HTTP/3 (2022) — работает поверх протокола QUIC (на основе UDP), обеспечивая более низкую задержку и устойчивость к потере пакетов.

По типу содержимого

• Запросы с телом (POST, PUT, PATCH) — передают данные.
• Запросы без тела (GET, HEAD, DELETE, OPTIONS) — не содержат данных.

По идемпотентности

• Идемпотентные (GET, HEAD, PUT, DELETE, OPTIONS, TRACE) — повторный запрос не изменяет состояние сервера.
• Неидемпотентные (POST, PATCH) — повторный запрос может привести к разным результатам.

Применение HTTP-запросов

HTTP-запросы являются основой для всех веб-технологий. Они используются в следующих сценариях:

• Веб-браузинг: браузер отправляет GET-запросы для загрузки HTML-страниц, изображений, стилей и скриптов. POST-запросы используются для отправки форм (логин, регистрация, поиск).
• REST API: большинство современных веб-сервисов (например, социальные сети, облачные хранилища, платёжные системы) предоставляют программные интерфейсы на основе HTTP-запросов. Клиент отправляет запросы с методами GET, POST, PUT, DELETE для управления ресурсами (пользователями, товарами, заказами).
• AJAX и SPA: в одностраничных приложениях (Single Page Application) JavaScript отправляет асинхронные HTTP-запросы (через объект XMLHttpRequest или Fetch API) для обновления части страницы без перезагрузки.
• Веб-хуки (webhooks): серверы отправляют HTTP-запросы (обычно POST) на указанный URL при наступлении события (например, новый заказ, обновление статуса).
• Прокси-серверы и кэширование: прокси-серверы перенаправляют HTTP-запросы, а кэширующие серверы (например, Varnish, CDN) хранят копии ответов на GET-запросы для ускорения загрузки.

Коды состояния ответа

В ответ на HTTP-запрос сервер возвращает HTTP-ответ, содержащий код состояния (status code). Коды делятся на пять классов:

• 1xx (Informational) — информационные (например, 101 Switching Protocols).
• 2xx (Success) — успешное выполнение (200 OK, 201 Created, 204 No Content).
• 3xx (Redirection) — перенаправление (301 Moved Permanently, 302 Found, 304 Not Modified).
• 4xx (Client Error) — ошибка клиента (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found).
• 5xx (Server Error) — ошибка сервера (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable).

Безопасность HTTP-запросов

HTTP-запросы передаются в открытом виде, что делает их уязвимыми для перехвата и модификации. Для защиты используется протокол HTTPS (HTTP over TLS), который шифрует содержимое запроса и ответа. Основные угрозы, связанные с HTTP-запросами:

• Перехват данных (Man-in-the-Middle) — злоумышленник может прочитать пароли, токены и личные данные.
• Подделка запросов (CSRF — Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос на сервер от её имени.
• SQL-инъекции и XSS — вредоносные данные в теле запроса или URI могут быть выполнены сервером или браузером.
• Атаки на аутентификацию — перебор паролей через POST-запросы.

Для защиты применяются: HTTPS, токены CSRF, валидация входных данных, ограничение частоты запросов (rate limiting), использование заголовков безопасности (например, Content-Security-Policy, X-Frame-Options).

Интересные факты

• Первый HTTP-запрос был отправлен в 1991 году Тимом Бернерсом-Ли в ЦЕРНе. Он использовал метод GET для запроса страницы с описанием проекта World Wide Web.
• Максимальная длина URI в HTTP-запросе не регламентирована стандартом, но большинство серверов ограничивают её 8–16 КБ (например, Apache — 8 КБ, IIS — 16 КБ).
• В HTTP/1.1 конвейерная обработка (pipelining) позволяла отправлять несколько запросов без ожидания ответа, но из-за проблем с реализацией она редко используется. В HTTP/2 эта проблема решена через мультиплексирование.
• Заголовок User-Agent часто подделывается браузерами и ботами для обхода ограничений или для совместимости.
• Метод TRACE редко используется в современных системах из-за уязвимости к атакам Cross-Site Tracing (XST).

Источники

• RFC 7230 — Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
• RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
• RFC 7540 — Hypertext Transfer Protocol Version 2 (HTTP/2)
• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport (HTTP/3)
• «HTTP: The Definitive Guide» by David Gourley, Brian Totty (O'Reilly Media, 2002)
• Документация MDN Web Docs — HTTP