«Кажется, что трёхзначные цифры в логах — это просто технические детали, но на деле это целый язык для разговора между компонентами системы. Понимая этот язык до уровня нюансов, можно не только чинить ошибки, но и проектировать более устойчивую архитектуру, видеть попытки атак там, где другие видят просто шум, и даже закладывать механизмы для будущих оптимизаций, которые появятся только в следующих версиях протокола.»
Код состояния HTTP — это трёхзначный номер, который сервер отправляет клиенту в самом начале ответа. Это не просто отметка «успех» или «ошибка», а стандартизированный способ сообщить о результате обработки запроса, от технических деталей рукопожатия до семантики бизнес-логики.
Информационные коды (1xx)
Коды 1xx — служебные. Они не завершают запрос, а передают промежуточные инструкции, часто невидимые для конечного пользователя, но критичные для оптимизации.
100 Continue
Используется, когда клиент отправляет большой объём данных (например, файл). Сервер проверяет начальные заголовки и, если всё в порядке, отправляет 100 Continue, давая зелёный свет на отправку тела запроса. Это предотвращает бессмысленную передачу гигабайтов данных, если запрос заранее обречён на ошибку аутентификации или лимита.
101 Switching Protocols
Ответ на запрос с заголовком Upgrade:. Сервер соглашается «переключить передачу» на другой протокол прямо в рамках этого соединения. Классический пример — переход с HTTP на WebSocket для двусторонней реальном времени связи. После этого ответа общение продолжается уже по новым правилам.
102 Processing (WebDAV)
Сервер получил запрос (часто сложный, как в WebDAV, работающий с файловой системой), начал его выполнять, но процесс займёт много времени. Этот код предотвращает таймаут клиента, сообщая: «Я не завис, я работаю».
103 Early Hints
Экспериментальный код, который позволяет серверу «вклиниться» до готовности основного ответа. Пока сервер генерирует тяжёлую страницу, он может отправить 103 с заголовками Link, указав браузеру на критически важные CSS или скрипты. Браузер начинает их предзагружать параллельно, сокращая общее время отклика.
Успешные коды (2xx)
Запрос успешно принят, понят и обработан. Но «успех» бывает разным.
200 OK
Универсальный код успеха. Семантика зависит от метода:
- GET: ресурс найден и передан в теле.
- HEAD: те же заголовки, что и для GET, но без тела.
- POST: результат операции (например, созданная сущность или статус) передан в теле.
- PUT, DELETE: результат обновления или удаления.
201 Created
Ресурс успешно создан в результате запроса (обычно POST или PUT). В ответе должен быть заголовок Location с URI нового ресурса. Это не просто «ок», а явное указание на факт создания, что важно для последующей логики клиента.
202 Accepted
Запрос принят в обработку, но она ещё не завершена. Операция может выполняться асинхронно, например, в очередь задач. Клиент должен позже запросить результат по другому URI (который можно передать в заголовке Location). Ключевое отличие от 200 — конечный результат пока неизвестен.
204 No Content
Сервер успешно выполнил запрос, но не возвращает никакого контента в теле. Клиент не должен обновлять отображение документа. Типичный сценарий — обработка данных формы AJAX-запросом, после которой интерфейс остаётся неизменным.
205 Reset Content
Аналог 204, но с инструкцией для клиента: сбросить представление документа, отправившего запрос (например, очистить поля формы).
206 Partial Content
Ответ на запрос с заголовком Range. Сервер возвращает только запрошенную часть ресурса. Основа для докачки файлов, потокового видео или аудио. В ответе содержится заголовок Content-Range, указывающий, какая часть передаётся.
Коды перенаправления (3xx)
Клиенту требуется предпринять дополнительное действие, обычно — отправить новый запрос по другому адресу. С точки зрения безопасности, неконтролируемые редиректы — вектор для фишинговых атак.
301 Moved Permanently
Ресурс навсегда перемещён на новый URI. Все будущие запросы должны использовать новый адрес. Поисковые системы переносят «вес» страницы на новый URL.
302 Found (ранее 302 Moved Temporarily)
Ресурс временно доступен по другому URI. Клиент должен продолжать использовать оригинальный URI для последующих запросов. Исторически сложилось, что многие клиенты и библиотеки меняли метод запроса на GET при редиректе, что порождало неопределённость.
303 See Other
Ответ на POST/PUT/DELETE, указывающий клиенту: чтобы получить результат, выполни GET по указанному в Location URI. Это предотвращает повторную отправку данных при обновлении страницы.
304 Not Modified
Условный GET. Клиент отправил заголовки (If-Modified-Since, If-None-Match), и ресурс не изменился. Сервер возвращает только заголовки, без тела, экономя трафик. Клиент использует кешированную копию.
307 Temporary Redirect и 308 Permanent Redirect
Современные аналоги 302 и 301 соответственно, с чётким правилом: метод и тело исходного запроса должны быть сохранены при перенаправлении. 308 гарантирует, что PUT-запрос будет перенаправлен как PUT, а не превратится в GET.
Клиентские ошибки (4xx)
Ошибка на стороне клиента: неверный запрос, отсутствие прав, конфликт. Мониторинг таких кодов, особенно паттернов 401, 403, 404, помогает выявлять сканирование уязвимостей и попытки подбора.
400 Bad Request
Общая ошибка из-за неверного синтаксиса запроса: сломанный JSON, некорректные заголовки, неверная кодировка.
401 Unauthorized
Требуется аутентификация. Ответ должен содержать заголовок WWW-Authenticate с указанием схемы аутентификации (например, Basic).
403 Forbidden
Сервер понял запрос, но отказывается его авторизовать. Даже при успешной аутентификации у клиента нет необходимых прав. Важно различать 401 («кто ты?») и 403 («тебе нельзя»).
404 Not Found
Сервер не нашёл запрашиваемый ресурс. Может означать как удалённую страницу, так и попытку доступа к несуществующему API-эндпоинту.
405 Method Not Allowed
Метод (POST, PUT, DELETE) не разрешён для данного URI. В ответе должен быть заголовок Allow со списком допустимых методов (например, Allow: GET, HEAD).
408 Request Timeout
Сервер решил разорвать неактивное соединение. Часто встречается в логах балансировщиков, которые закрывают «висящие» соединения от клиентов.
409 Conflict
Запрос конфликтует с текущим состоянием ресурса, например, попытка изменить данные на основе устаревшей версии (оптимистичная блокировка). В ответе можно передать информацию о конфликте для его разрешения клиентом.
413 Payload Too Large
Размер тела запроса превышает лимит, установленный сервером. Защита от DoS-атак, связанных с переполнением.
414 URI Too Long
Длина URI превышает допустимую для сервера. Часто возникает при передаче большого количества параметров в GET-запросе.
415 Unsupported Media Type
Сервер отказывается обрабатывать запрос, потому что медиатип данных в теле (указанный в Content-Type) ему не поддерживается.
429 Too Many Requests
Клиент исчерпал лимит запросов (rate limiting). В ответе часто указывается заголовок Retry-After с рекомендуемой паузой. Критически важный код для защиты API.
Серверные ошибки (5xx)
Сервер не смог выполнить валидный запрос по своей вине. Резкий рост таких ошибок — сигнал о серьёзных проблемах в инфраструктуре.
500 Internal Server Error
Универсальная ошибка сервера, когда более конкретный код 5xx неприменим. Часто означает необработанное исключение в коде приложения.
502 Bad Gateway
Сервер (балансировщик, обратный прокси) получил недопустимый ответ от вышестоящего сервера (бэкенда), к которому он обратился.
503 Service Unavailable
Сервис временно недоступен из-за перегрузки или техобслуживания. Ответ может содержать Retry-After. Важно, чтобы такие ответы не кешировались.
504 Gateway Timeout
Таймаут ожидания ответа от вышестоящего сервера. Проблема не в обработке, а в коммуникации между компонентами.
507 Insufficient Storage (WebDAV)
На сервере недостаточно места для выполнения запроса (например, при загрузке файла).
Понимание этих кодов выходит за рамки отладки. Анализ их распределения помогает оценивать здоровье системы, проектировать отказоустойчивость (например, через 429 и 503) и строить безопасность, где каждый нестандартный редирект (3xx) или последовательность 4xx-ошибок становится индикатором зондирования системы.