Запросы HTTP протокола — это сообщения, с помощью которых браузер, мобильное приложение или другая программа обращается к серверу. Сервер принимает запрос, анализирует его метод, URL, заголовки и тело, а затем возвращает ответ со статусом, заголовками и данными. Понимание этой последовательности помогает разбираться в работе сайтов, API, авторизации, загрузке файлов и причинах ошибок вроде 404 или 500.
HTTP-сообщение — это не абстрактная команда, а вполне конкретный текстовый или бинарный обмен: клиент сообщает, что ему нужно, а сервер отвечает, удалось ли выполнить операцию и какие данные следует вернуть.
Ниже последовательно разберём, как устроены сообщения протокола HTTP, чем запрос отличается от ответа, зачем нужны методы и заголовки, как читать коды состояния и где именно передаются параметры. Отдельное внимание уделим практическим примерам для сайта cio-navigator.ru, чтобы теория не оставалась набором непонятных терминов.
- Иерархия знаний по HTTP
- Что такое HTTP-запрос и HTTP-ответ
- Как клиент отправляет HTTP-запрос
- Как сервер формирует HTTP-ответ
- Связь между запросом и ответом
- Структура HTTP-запроса
- Стартовая строка запроса
- Заголовки HTTP-запроса
- Тело HTTP-запроса
- URL и параметры запроса
- Query-параметры
- Данные в теле запроса
- Структура HTTP-ответа
- Строка состояния
- Заголовки ответа
- Тело HTTP-ответа
- Методы HTTP-запросов — Таблица
- GET
- POST
- PUT
- PATCH
- DELETE
- HEAD
- OPTIONS
- Заголовки HTTP
- Что такое HTTP-заголовки
- Заголовки запроса
- Заголовки ответа
- Content-Type
- Content-Length
- Authorization
- Accept
- User-Agent
- Коды состояния HTTP — Таблица
- Коды 1xx
- Коды 2xx
- Коды 3xx
- Коды 4xx
- Коды 5xx
- Как выглядит HTTP-запрос — Пример
- Как выглядит HTTP-ответ — Пример
- HTTP GET и POST — сравнение — Таблица
- Типичные ошибки HTTP
- Ошибки 400 и 401
- Ошибки 403 и 404
- Ошибки 500, 502 и 503
- Связь HTTP-запроса с другими частями HTTP
- Частые вопросы
- Из чего состоит HTTP-запрос?
- Из чего состоит HTTP-ответ?
- Что такое HTTP-заголовок?
- Чем GET отличается от POST?
- Что означает код 404?
Иерархия знаний по HTTP
HTTP проще изучать не как разрозненный список правил, а как систему взаимосвязанных тем. Сначала полезно понять общую модель протокола, затем перейти к структуре сообщений, версиям, HTTPS, сетевому уровню, API и инструментам диагностики.
HTTP ├── HTTP: что это такое и как работает протокол ├── HTTP-запрос и HTTP-ответ: структура, методы, заголовки и коды ├── Версии HTTP: HTTP/1.0, HTTP/1.1, HTTP/2 и HTTP/3 ├── HTTP и HTTPS: разница, безопасность и шифрование ├── HTTP в сетевой модели: TCP/IP, OSI, IP, DNS и порты ├── HTTP-сервер, URL и передача файлов: как работает веб ├── HTTP, API, REST, JSON и XML: как приложения обмениваются данными └── HTTP: настройка, проверка и отладка
Эта статья посвящена центральному элементу такой иерархии — обмену между клиентом и сервером. Здесь будут разобраны протокол HTTP структура запроса ответа, назначение отдельных строк и правила интерпретации результата.
Что такое HTTP-запрос и HTTP-ответ
HTTP работает по модели «клиент — сервер». Клиентом может быть браузер, программа командной строки, мобильное приложение, поисковый робот или другой сервер. Он отправляет запрос на определённый ресурс, а сервер возвращает ответ. В простейшем случае браузер просит HTML-страницу, но тем же механизмом загружаются изображения, таблицы стилей, JSON-данные и файлы.
Главная идея HTTP проста: запрос описывает намерение клиента, а ответ сообщает результат обработки.
В классической модели HTTP обмен инициируется клиентом. Сервер обычно не отправляет данные сам по себе, пока не получил запрос, хотя современные технологии — WebSocket, Server-Sent Events и HTTP/2 Server Push — позволяют строить более сложные сценарии.
| Участник | Что делает | Пример |
|---|---|---|
| Клиент | Формирует и отправляет HTTP-запрос | Браузер запрашивает /about/ |
| Сервер | Принимает запрос и выбирает обработчик | Веб-сервер передаёт запрос приложению |
| Приложение | Проверяет данные, обращается к базе, формирует результат | CMS собирает HTML-страницу |
| Сервер | Возвращает HTTP-ответ | Статус 200 и тело с HTML |
Как клиент отправляет HTTP-запрос
Перед отправкой клиент определяет схему соединения, доменное имя, порт, путь и метод. Для HTTPS дополнительно устанавливается защищённое TLS-соединение. Затем клиент формирует стартовую строку, добавляет заголовки и, если нужно, тело запроса.
Например, при открытии страницы https://cio-navigator.ru/http/ браузер сначала получает IP-адрес домена через DNS, устанавливает соединение с сервером и отправляет запрос примерно такого вида:
GET /http/ HTTP/1.1 Host: cio-navigator.ru Accept: text/html,application/xhtml+xml User-Agent: Mozilla/5.0
В HTTP/1.1 заголовок Host обязателен: один IP-адрес может обслуживать множество доменов, и серверу нужно понимать, какой именно сайт запрашивается.
Как сервер формирует HTTP-ответ
Сервер читает запрос сверху вниз: определяет метод, ресурс, заголовки и тело. После этого он проверяет права доступа, ищет файл или запускает программный обработчик, а затем формирует строку состояния, заголовки и тело ответа.
| Этап | Вопрос сервера | Возможный результат |
|---|---|---|
| Маршрутизация | Какой ресурс запрошен? | /http/ → обработчик статьи |
| Проверка метода | Разрешён ли GET или POST? | GET разрешён, DELETE запрещён |
| Авторизация | Есть ли у клиента нужные права? | Доступ разрешён или 403 Forbidden |
| Подготовка данных | Что вернуть клиенту? | HTML, JSON, изображение или ошибка |
| Формирование ответа | Как описать результат? | Статус 200, Content-Type, тело |
Ответ не обязательно содержит запрошенную страницу. Если ресурс перемещён, сервер может вернуть 301 или 302; если клиент не авторизован — 401; если страница отсутствует — 404. Поэтому код состояния является не украшением, а важной частью смысла ответа.
Связь между запросом и ответом
Один запрос обычно получает один ответ, но внутри страницы браузер может отправить десятки дополнительных запросов: за CSS, JavaScript, изображениями, шрифтами и данными API. Каждый такой обмен имеет собственный набор заголовков и собственный код состояния.
Запрос: GET /http/ HTTP/1.1 Host: cio-navigator.ru Ответ: HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 <!doctype html> ...
Важно различать HTTP-сообщение и сетевой пакет. Пакет протокола HTTP — бытовое, но не всегда точное выражение: HTTP-сообщение может передаваться через несколько TCP-сегментов или QUIC-пакетов. На уровне приложения мы анализируем именно сообщение, а не отдельный физический фрагмент передачи.
Структура HTTP-запроса
Протокол HTTP состоит из стартовой строки, заголовков, пустой строки-разделителя и необязательного тела. В HTTP/1.1 эти элементы видны почти буквально в виде текста. В HTTP/2 и HTTP/3 информация передаётся в бинарной форме, но логическая структура остаётся похожей.
Чтобы понять структуру протокола HTTP, достаточно задать четыре вопроса: какой метод используется, какой ресурс запрошен, какие условия переданы в заголовках и есть ли данные в теле.
| Часть запроса | Обязательность | Назначение | Пример |
|---|---|---|---|
| Стартовая строка | Да | Метод, путь и версия протокола | GET /http/ HTTP/1.1 |
| Заголовки | Обычно нужны | Метаданные и условия обработки | Host, Accept, Authorization |
| Пустая строка | Да как разделитель | Отделяет заголовки от тела | Пустая строка |
| Тело | Не всегда | Передаёт данные клиента | JSON, форма, файл |
Стартовая строка запроса
Стартовая строка имеет формат METHOD target HTTP/version. Метод сообщает намерение клиента, target обычно содержит путь и query-параметры, а версия определяет правила обмена.
POST /api/articles?draft=true HTTP/1.1
В этом примере POST указывает на отправку данных, путь равен /api/articles, параметр draft=true уточняет режим обработки, а HTTP/1.1 — используемая версия протокола.
В запросе к серверу также может использоваться абсолютный URL, особенно при обращении к прокси:
GET https://cio-navigator.ru/http/ HTTP/1.1
Заголовки HTTP-запроса
Заголовки передают метаданные: предпочитаемый формат ответа, тип тела, язык, сведения о клиенте, cookies и учётные данные. Они не являются обычным текстом для пользователя — это инструкции и характеристики, которые читают сервер, прокси или промежуточные системы.
| Заголовок | Что описывает | Пример значения |
|---|---|---|
| Host | Домен назначения | cio-navigator.ru |
| Accept | Форматы, приемлемые клиенту | text/html, application/json |
| Content-Type | Формат тела запроса | application/json |
| Authorization | Данные для аутентификации | Bearer eyJ… |
| User-Agent | Описание клиентского приложения | Mozilla/5.0 |
Заголовки отделяются от тела пустой строкой. Если пустой строки нет, сервер может не понять, где заканчиваются метаданные и начинаются данные. В текстовом представлении каждая строка обычно завершается последовательностью CRLF.
Тело HTTP-запроса
Тело используется, когда клиент передаёт серверу содержимое: поля формы, JSON-документ, XML, изображение или файл. У GET-запроса тело технически возможно в некоторых реализациях, но его поддержка непредсказуема, поэтому данные для GET обычно помещают в URL.
POST /api/search HTTP/1.1
Host: cio-navigator.ru
Content-Type: application/json
Content-Length: 31
{"query":"HTTP","page":1}
Заголовок Content-Type объясняет, как интерпретировать тело, а Content-Length сообщает его размер в байтах. Вместо Content-Length может использоваться потоковая передача с Transfer-Encoding: chunked в HTTP/1.1.
URL и параметры запроса
URL состоит из нескольких частей: схемы, домена, порта, пути, строки запроса и иногда фрагмента. Фрагмент после символа # обычно не отправляется на сервер — его обрабатывает браузер внутри уже загруженного документа.
| Часть URL | Пример | Роль |
|---|---|---|
| Схема | https | Определяет способ соединения |
| Домен | cio-navigator.ru | Имя сервера |
| Порт | :443 | Точка подключения |
| Путь | /http/ | Запрашиваемый ресурс |
| Query | ?page=2 | Параметры запроса |
| Фрагмент | #headers | Якорь внутри документа, серверу обычно не передаётся |
Query-параметры
Query-параметры начинаются после знака вопроса и состоят из пар «имя=значение», разделённых амперсандом. Они подходят для фильтрации, сортировки, пагинации и поиска, то есть для уточнения того, какие данные нужно получить.
GET /http/?page=2&format=short HTTP/1.1 Host: cio-navigator.ru
Значения необходимо корректно кодировать. Пробел в URL может быть представлен как %20 или + в формах, а кириллица передаётся в percent-encoding. Нельзя помещать в URL пароли, токены и другую секретную информацию: URL часто сохраняется в истории, логах и аналитике.
Данные в теле запроса
Тело предпочтительнее query-параметров, когда клиент создаёт или изменяет ресурс, отправляет большой объём данных или передаёт структурированный документ. Формат тела должен быть явно указан.
| Формат | Content-Type | Когда применяется |
|---|---|---|
| HTML-форма | application/x-www-form-urlencoded | Простые поля формы |
| Многочастные данные | multipart/form-data | Форма с файлами |
| JSON | application/json | REST API и обмен объектами |
| XML | application/xml | Интеграции и старые корпоративные API |
| Бинарные данные | application/octet-stream | Произвольный файл или поток байтов |
POST /api/feedback HTTP/1.1 Host: cio-navigator.ru Content-Type: application/x-www-form-urlencoded name=Ivan&message=Hello
Структура HTTP-ответа
Ответ сервера устроен сходным образом: строка состояния, заголовки, пустая строка и необязательное тело. Однако вместо метода и пути в первой строке находятся версия протокола, числовой статус и краткая текстовая причина.
Один и тот же URL может возвращать разные ответы в зависимости от метода, заголовков, авторизации, cookies и состояния ресурса.
| Часть ответа | Пример | Назначение |
|---|---|---|
| Строка состояния | HTTP/1.1 200 OK | Результат обработки |
| Заголовки | Content-Type: text/html | Метаданные ответа |
| Пустая строка | — | Разделитель |
| Тело | <html>…</html> | Содержимое ресурса |
Строка состояния
Строка состояния имеет формат HTTP/version status-code reason-phrase. Числовой код важен для программ, а текстовая фраза удобна человеку. Программа должна ориентироваться прежде всего на код, поскольку текстовая часть может изменяться или отсутствовать в новых версиях протокола.
HTTP/1.1 404 Not Found
Первая цифра кода определяет класс результата: 1xx — информационный, 2xx — успешный, 3xx — перенаправление, 4xx — ошибка клиента, 5xx — ошибка сервера.
Заголовки ответа
Заголовки ответа описывают возвращаемые данные, правила кэширования, cookies, перенаправления и параметры безопасности. Например, Content-Type сообщает браузеру, что тело является HTML-документом, а Location указывает новый URL при редиректе.
HTTP/1.1 200 OK Date: Tue, 12 Mar 2024 10:00:00 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 1280 Cache-Control: max-age=3600 X-Content-Type-Options: nosniff
Тело HTTP-ответа
Тело содержит фактический результат: HTML, JSON, изображение, CSS, JavaScript или текстовое описание ошибки. У ответов 204 No Content и 304 Not Modified тела обычно нет, а у HEAD тело не передаётся по определению, хотя заголовки должны описывать аналогичный GET-ответ.
Тип и размер тела определяются заголовками. Если сервер возвращает сжатые данные, он может добавить Content-Encoding: gzip или br. Клиент распаковывает тело перед передачей его приложению.
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 48
{"status":"ok","site":"cio-navigator.ru"}
Методы HTTP-запросов — Таблица
Метод показывает, какую операцию хочет выполнить клиент. Это не просто условное слово: метод влияет на кэширование, повторяемость операции, допустимость тела и требования к безопасности.
| Метод | Назначение | Типичные сценарии | Особенности |
|---|---|---|---|
| GET | Получить ресурс | Страница, файл, список API | Не должен изменять состояние; может кэшироваться |
| POST | Передать данные для обработки | Создание записи, форма, запуск операции | Обычно не идемпотентен |
| PUT | Создать или полностью заменить ресурс | Полное обновление объекта | Идемпотентен при корректной реализации |
| PATCH | Частично изменить ресурс | Изменение одного поля | Формат изменений зависит от API |
| DELETE | Удалить ресурс | Удаление записи или файла | Повторный вызов обычно не меняет результат |
| HEAD | Получить только заголовки | Проверка доступности и размера | Тело ответа не передаётся |
| OPTIONS | Узнать поддерживаемые возможности | CORS preflight, диагностика API | Может вернуть Allow |
GET
GET используется для получения представления ресурса. Хороший GET-запрос не должен менять данные на сервере: повторное обновление страницы не должно создавать новые записи или списывать деньги.
GET /http/ HTTP/1.1 Host: cio-navigator.ru Accept: text/html User-Agent: Mozilla/5.0
GET может содержать параметры фильтрации и сортировки в URL. Ответы на GET часто кэшируются браузером, CDN или прокси, если сервер разрешил это заголовками.
POST
POST передаёт данные обработчику. Метод применяют для создания ресурса, отправки формы, загрузки файла или запуска действия, которое нельзя выразить простым получением URL.
POST /api/search HTTP/1.1
Host: cio-navigator.ru
Content-Type: application/json
Accept: application/json
{"query":"HTTP-запрос","page":1}
Повторная отправка POST может создать два одинаковых заказа или два обращения. Поэтому для важных операций используют защиту от повторов: уникальный идентификатор операции, Idempotency-Key или проверку на стороне приложения.
PUT
PUT обычно означает полную замену ресурса по указанному адресу. Если клиент отправит один и тот же PUT несколько раз, итоговое состояние должно оставаться одинаковым — это свойство называется идемпотентностью.
PUT /api/articles/42 HTTP/1.1
Host: cio-navigator.ru
Content-Type: application/json
{"title":"HTTP","status":"published","content":"Обновлённый текст"}
PATCH
PATCH предназначен для частичного изменения. В отличие от PUT, клиент не обязан передавать весь объект — только изменяемые поля или инструкцию изменения.
PATCH /api/articles/42 HTTP/1.1
Host: cio-navigator.ru
Content-Type: application/json
{"status":"published"}
Конкретная форма PATCH определяется API. Это может быть обычный JSON с полями, JSON Merge Patch или JSON Patch с массивом операций.
DELETE
DELETE просит удалить ресурс. Удаление может быть физическим, логическим или помещать объект в корзину — HTTP сам по себе не диктует внутренний способ.
DELETE /api/articles/42 HTTP/1.1 Host: cio-navigator.ru Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Успешный ответ может иметь статус 204 No Content, 200 OK с описанием результата или 202 Accepted, если удаление выполняется асинхронно.
HEAD
HEAD повторяет семантику GET, но сервер не должен отправлять тело. Это удобно, когда нужно узнать размер файла, дату изменения или проверить доступность ресурса без скачивания содержимого.
HEAD /http/ HTTP/1.1 Host: cio-navigator.ru Accept: text/html
OPTIONS
OPTIONS позволяет узнать доступные методы и используется браузерами перед некоторыми кросс-доменными запросами. Такой предварительный запрос называется CORS preflight.
OPTIONS /api/articles HTTP/1.1 Host: cio-navigator.ru Origin: https://example.com Access-Control-Request-Method: POST
Заголовки HTTP
HTTP-заголовки — это пары «имя: значение», сопровождающие запрос или ответ. Они позволяют передавать служебную информацию, не смешивая её с основным содержимым. Заголовки могут добавляться браузером, сервером, прокси, CDN и прикладным кодом.
Заголовок не меняет сам ресурс; он сообщает, как именно следует понимать, передавать или обрабатывать сообщение.
Что такое HTTP-заголовки
Имена заголовков нечувствительны к регистру: Content-Type и content-type обозначают одно и то же поле. Значение зависит от конкретного заголовка и может включать параметры, например кодировку символов.
| Группа | Примеры | Назначение |
|---|---|---|
| Представление | Content-Type, Content-Encoding | Описание формата и кодирования тела |
| Кэширование | Cache-Control, ETag, If-None-Match | Управление повторным использованием ответа |
| Аутентификация | Authorization, WWW-Authenticate | Подтверждение личности и запроса учётных данных |
| Безопасность | Strict-Transport-Security, CSP | Ограничение опасных сценариев |
| Маршрутизация | Host, Location | Выбор домена и нового адреса |
Заголовки запроса
Запросные заголовки описывают клиента и его ожидания. Например, Accept позволяет выбрать формат ответа, а If-Modified-Since помогает не скачивать неизменившийся ресурс повторно.
Заголовки ответа
Ответные заголовки описывают серверный результат. Set-Cookie устанавливает cookie, Location задаёт адрес перенаправления, а Vary предупреждает кэш о том, что результат зависит от конкретного запросного заголовка.
GET /http/ HTTP/1.1 Host: cio-navigator.ru Accept: text/html,application/xhtml+xml Accept-Encoding: gzip, deflate, br Accept-Language: ru-RU,ru;q=0.9,en;q=0.8 Cache-Control: max-age=0 Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Cookie: session_id=abc123 HTTP/1.1 200 OK Date: Tue, 12 Mar 2024 10:00:00 GMT Server: nginx Content-Type: text/html; charset=UTF-8 Content-Encoding: gzip Content-Length: 1842 Cache-Control: public, max-age=3600 ETag: "a1b2c3" Vary: Accept-Encoding X-Content-Type-Options: nosniff [сжатое тело HTML]
Content-Type
Content-Type показывает MIME-тип тела. Для HTML обычно используется text/html, для JSON — application/json, для изображения PNG — image/png. Параметр charset уточняет кодировку символов.
Content-Type: application/json; charset=UTF-8
Content-Type запроса и ответа — не одно и то же. В запросе он описывает отправленные данные, а в ответе — возвращённые сервером.
Content-Length
Content-Length указывает длину тела в байтах, а не количество символов. Это различие важно для UTF-8: русская буква обычно занимает несколько байтов.
Content-Length: 48
При сжатии значение относится к передаваемому, уже сжатому телу. Если используется chunked-передача, Content-Length может отсутствовать.
Authorization
Authorization передаёт данные аутентификации. Популярная схема Bearer используется с токенами доступа, Basic — с кодированными именем пользователя и паролем. Base64 в Basic не является шифрованием, поэтому такой вариант допустим только поверх HTTPS.
GET /api/profile HTTP/1.1 Host: cio-navigator.ru Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
Accept
Accept сообщает, какие форматы ответа способен обработать клиент. Сервер может выбрать наиболее подходящий формат или вернуть 406 Not Acceptable, если подходящего представления нет.
Accept: application/json, text/html;q=0.9, */*;q=0.8
Параметр q задаёт относительный приоритет: чем выше значение, тем предпочтительнее формат.
User-Agent
User-Agent содержит описание клиента. Серверы используют его для статистики, совместимости и иногда адаптации содержимого, однако полагаться на него как на надёжный признак нельзя: строку легко изменить.
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 Chrome/122.0 Safari/537.36
Коды состояния HTTP — Таблица
Коды ответа протокола HTTP позволяют быстро понять, чем завершилась обработка запроса. Код 4xx обычно указывает на проблему в запросе или правах клиента, а 5xx — на сбой сервера или промежуточного узла.
| Код | Название | Значение | Что обычно делать |
|---|---|---|---|
| 200 | OK | Запрос успешно выполнен | Использовать тело ответа |
| 201 | Created | Ресурс создан | Проверить Location и тело |
| 301 | Moved Permanently | Постоянное перенаправление | Обновить ссылку или кэш |
| 302 | Found | Временное перенаправление | Перейти по Location временно |
| 304 | Not Modified | Ресурс не изменился | Взять копию из кэша |
| 400 | Bad Request | Некорректный запрос | Проверить синтаксис и данные |
| 401 | Unauthorized | Нет корректной аутентификации | Передать или обновить учётные данные |
| 403 | Forbidden | Доступ запрещён | Проверить права и политики |
| 404 | Not Found | Ресурс не найден | Проверить URL и маршрутизацию |
| 405 | Method Not Allowed | Метод запрещён для ресурса | Проверить Allow и документацию API |
| 408 | Request Timeout | Клиент не успел отправить запрос | Проверить сеть и тайм-ауты |
| 409 | Conflict | Конфликт состояния ресурса | Синхронизировать данные |
| 429 | Too Many Requests | Слишком много запросов | Снизить частоту, учесть Retry-After |
| 500 | Internal Server Error | Внутренняя ошибка приложения | Изучить серверные логи |
| 502 | Bad Gateway | Плохой ответ вышестоящего сервера | Проверить прокси и upstream |
| 503 | Service Unavailable | Сервис временно недоступен | Повторить позже, проверить нагрузку |
| 504 | Gateway Timeout | Upstream не ответил вовремя | Проверить тайм-ауты и зависимые сервисы |
Один и тот же код может иметь разные причины. Например, 404 бывает результатом опечатки в URL, удалённой страницы или неправильно настроенного маршрута. Поэтому код — это отправная точка диагностики, а не полный отчёт о неисправности.
Коды 1xx
Информационные ответы 1xx сообщают о промежуточном состоянии. Наиболее известен 100 Continue: сервер подтверждает, что клиент может продолжать отправку тела запроса.
POST /api/upload HTTP/1.1 Host: cio-navigator.ru Expect: 100-continue Content-Length: 10485760 HTTP/1.1 100 Continue
После такого ответа клиент отправляет тело. В обычной отладке коды 1xx могут быть незаметны, потому что библиотека скрывает их от прикладного кода.
Коды 2xx
Класс 2xx означает успешную обработку. 200 подходит для обычного результата, 201 — для создания ресурса, 202 — для принятой, но ещё не завершённой операции, а 204 — для успешного результата без тела.
POST /api/articles HTTP/1.1
Host: cio-navigator.ru
Content-Type: application/json
{"title":"Новая статья"}
HTTP/1.1 201 Created
Location: /api/articles/43
Content-Type: application/json
{"id":43,"title":"Новая статья"}
Коды 3xx
Коды 3xx связаны с перенаправлением или кэшированием. Для редиректов важен заголовок Location. Код 304 не означает ошибку: сервер сообщает, что клиент может использовать сохранённую копию.
GET /old-http-page HTTP/1.1 Host: cio-navigator.ru HTTP/1.1 301 Moved Permanently Location: https://cio-navigator.ru/http/
GET /http/ HTTP/1.1 Host: cio-navigator.ru If-None-Match: "a1b2c3" HTTP/1.1 304 Not Modified ETag: "a1b2c3"
Коды 4xx
Коды 4xx указывают, что сервер не может или не должен выполнить запрос в представленном виде. Это может быть неверный JSON, отсутствие токена, недостаток прав, неправильный метод или слишком частые обращения.
GET /private HTTP/1.1
Host: cio-navigator.ru
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
Content-Type: application/json
{"error":"authentication_required"}
Коды 5xx
Коды 5xx означают проблему на серверной стороне или между серверами. Если сайт использует reverse proxy, CDN и отдельное приложение, ошибка может возникнуть на любом звене цепочки.
GET /api/articles HTTP/1.1 Host: cio-navigator.ru HTTP/1.1 502 Bad Gateway Content-Type: text/html; charset=UTF-8 <html><body>Bad Gateway</body></html>
Ошибка протокола HTTP не всегда означает поломку самого HTTP. Часто протокол исправно доставил запрос, а проблема возникла в приложении, базе данных, прокси или внешнем сервисе.
Как выглядит HTTP-запрос — Пример
Рассмотрим полный GET-запрос к странице cio-navigator.ru. В нём нет тела: клиенту достаточно указать ресурс и сообщить серверу свои предпочтения.
GET /http/ HTTP/1.1 Host: cio-navigator.ru Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip, deflate, br Accept-Language: ru-RU,ru;q=0.9 Connection: keep-alive User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/122.0 Safari/537.36
Разбор примера выглядит так:
- GET — запрос на получение ресурса;
- /http/ — путь страницы;
- HTTP/1.1 — версия протокола;
- Host — домен, к которому обращается клиент;
- Accept — предпочтительные форматы ответа;
- Accept-Encoding — поддерживаемые способы сжатия;
- User-Agent — сведения о клиенте;
- пустая строка — признак окончания заголовков и отсутствия тела.
Как выглядит HTTP-ответ — Пример
Теперь сервер возвращает HTML-документ. Размер тела в примере условный, поскольку реальный объём страницы зависит от содержимого, сжатия и настроек сервера.
HTTP/1.1 200 OK Date: Tue, 12 Mar 2024 10:00:00 GMT Server: nginx Content-Type: text/html; charset=UTF-8 Content-Length: 96 Cache-Control: public, max-age=3600 ETag: "page-http-20240312" X-Content-Type-Options: nosniff <!doctype html> <html lang="ru"> <head><title>HTTP</title></head> <body>Страница о протоколе HTTP</body> </html>
Клиент видит статус 200 и понимает, что обработка успешна. Content-Type говорит браузеру отобразить тело как HTML, charset задаёт кодировку, Cache-Control разрешает кэширование, а ETag помогает позднее проверить, изменился ли документ.
HTTP GET и POST — сравнение — Таблица
GET и POST встречаются чаще остальных методов, поэтому их различия важно понимать не только на уровне «у одного есть тело, у другого нет». Их семантика влияет на безопасность, кэширование, повторную отправку и проектирование API.
| Критерий | GET | POST |
|---|---|---|
| Основное назначение | Получение ресурса | Передача данных для обработки |
| Параметры | Обычно находятся в URL | Обычно находятся в теле |
| Тело запроса | Как правило, отсутствует | Часто используется |
| Кэширование | Часто возможно | Обычно не кэшируется автоматически |
| Видимость данных | Параметры видны в URL и логах | Тело не отображается в адресной строке, но всё равно должно защищаться HTTPS |
| Идемпотентность | Должна сохраняться | Не гарантируется |
| Пример | Поиск, просмотр статьи | Форма, создание записи |
POST не является автоматически «безопасным», а GET не является способом защитить данные. Секреты нельзя передавать ни в URL, ни в незащищённом теле. Для конфиденциальности нужен HTTPS, а для защиты от повторной отправки и CSRF — дополнительные прикладные механизмы.
Типичные ошибки HTTP
При диагностике ошибки полезно отделять код от причины. Один и тот же статус может появиться из-за разных настроек, поэтому следует смотреть URL, метод, заголовки, тело запроса и серверные журналы.
Ошибки 400 и 401
400 означает, что сервер не смог корректно разобрать запрос. Частые причины — повреждённый JSON, отсутствующее обязательное поле, неверный query-параметр или слишком большой заголовок. 401 связан с отсутствием корректной аутентификации.
POST /api/search HTTP/1.1
Host: cio-navigator.ru
Content-Type: application/json
{"query":
HTTP/1.1 400 Bad Request
Content-Type: application/json
{"error":"invalid_json"}
GET /api/profile HTTP/1.1
Host: cio-navigator.ru
Authorization: Bearer expired-token
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer
Content-Type: application/json
{"error":"invalid_token"}
При 400 нужно проверять формат и обязательные поля, а при 401 — наличие токена, его срок действия, схему Authorization и корректность передачи cookies.
Ошибки 403 и 404
403 означает, что сервер понял запрос, но отказал в доступе. 404 сообщает, что ресурс не найден или сервер намеренно не раскрывает его существование. Разница важна: исправление URL помогает при 404, но не решает проблему отсутствующих прав при 403.
DELETE /api/articles/42 HTTP/1.1
Host: cio-navigator.ru
Authorization: Bearer user-token
HTTP/1.1 403 Forbidden
Content-Type: application/json
{"error":"insufficient_permissions"}
GET /http/does-not-exist/ HTTP/1.1 Host: cio-navigator.ru HTTP/1.1 404 Not Found Content-Type: text/html; charset=UTF-8 <h1>Страница не найдена</h1>
Для 404 проверяют слеши, регистр пути, правила rewrite, маршруты приложения и наличие файла. Для 403 дополнительно изучают ACL, роли пользователя, настройки веб-сервера и правила WAF.
Ошибки 500, 502 и 503
500 говорит о внутреннем исключении или другой необработанной проблеме приложения. 502 часто возвращает reverse proxy, когда не получил корректный ответ от upstream. 503 означает временную недоступность: перегрузку, технические работы или отсутствие готового экземпляра приложения.
GET /api/report HTTP/1.1
Host: cio-navigator.ru
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{"error":"internal_server_error","request_id":"req-7f31"}
GET /api/news HTTP/1.1 Host: cio-navigator.ru HTTP/1.1 502 Bad Gateway Content-Type: text/plain upstream prematurely closed connection
GET /api/articles HTTP/1.1
Host: cio-navigator.ru
HTTP/1.1 503 Service Unavailable
Retry-After: 60
Content-Type: application/json
{"error":"service_temporarily_unavailable"}
Пользователю при 5xx обычно достаточно повторить операцию позже, если она безопасна. Администратору нужно проверить логи приложения, состояние базы данных, соединения между сервисами, лимиты ресурсов и тайм-ауты прокси.
Связь HTTP-запроса с другими частями HTTP
Основная статья: HTTP: что это такое и как работает протокол
Структура запроса и ответа — только один уровень общей модели HTTP. Сначала DNS превращает доменное имя в IP-адрес, затем транспортный протокол устанавливает соединение, а HTTP передаёт прикладные сообщения. При HTTPS между HTTP и транспортом добавляется TLS, который шифрует содержимое и проверяет сертификат сервера.
| Уровень | Что происходит | Пример |
|---|---|---|
| DNS | Имя преобразуется в IP-адрес | cio-navigator.ru → 203.0.113.10 |
| TCP или QUIC | Создаётся транспортный обмен | TCP:443 или QUIC/UDP:443 |
| TLS | Устанавливается шифрование HTTPS | Проверка сертификата |
| HTTP | Передаются запросы и ответы | GET, заголовки, статус, тело |
| Приложение | Обрабатываются бизнес-правила | Поиск статьи или создание записи |
Версия HTTP тоже меняет способ передачи, но не отменяет базовые понятия. В HTTP/1.1 строки и заголовки обычно видны в текстовом виде. HTTP/2 использует бинарные фреймы и мультиплексирование потоков, HTTP/3 работает поверх QUIC. При этом метод, статус, заголовки и тело остаются понятными концепциями для разработчика.
На практике для анализа используют инструменты разработчика браузера, curl, Postman, журналы reverse proxy и трассировку приложения. Важно помнить: просмотр через браузер может скрывать часть технических деталей, автоматически добавлять cookies, следовать редиректам и распаковывать сжатые ответы.
curl -i -X GET "https://cio-navigator.ru/http/" -H "Accept: text/html" -A "HTTP-Diagnostic-Client/1.0"
Частые вопросы
Ниже собраны короткие ответы на вопросы, которые чаще всего возникают при чтении HTTP-трафика.
Из чего состоит HTTP-запрос?
HTTP-запрос состоит из стартовой строки, заголовков, пустой строки и необязательного тела. В стартовой строке находятся метод, путь с параметрами и версия протокола. В теле передаются JSON, данные формы, файл или другой контент.
Из чего состоит HTTP-ответ?
HTTP-ответ включает строку состояния, заголовки, пустую строку и необязательное тело. Строка состояния содержит версию протокола, числовой код и текстовое описание результата.
Что такое HTTP-заголовок?
HTTP-заголовок — это поле с именем и значением, которое описывает запрос или ответ. Заголовки передают тип содержимого, размер, авторизацию, сведения о клиенте, правила кэширования и другие метаданные.
Чем GET отличается от POST?
GET предназначен главным образом для получения ресурса, а POST — для передачи данных на обработку. Параметры GET обычно находятся в URL и могут кэшироваться, тогда как данные POST чаще помещаются в тело и обычно не кэшируются автоматически.
Что означает код 404?
404 Not Found означает, что сервер не нашёл ресурс по указанному адресу либо не хочет сообщать о его существовании. Нужно проверить URL, маршрут, домен, наличие конечного слеша и настройки перенаправлений.
Понимание того, как выглядит протокол HTTP, превращает диагностику веб-проблем из гадания в последовательный анализ: сначала проверяется запрос, затем ответ, после этого — маршрутизация, права, приложение и инфраструктура. Именно так раскрывается формат протокола HTTP и становится понятной вся цепочка обмена между клиентом и сервером.
