Ошибка 414 URI Too Long

HTTP 414 URI Too Long означает, что URI запроса длиннее, чем сервер или промежуточный компонент готов интерпретировать. Чаще всего проблема связана с чрезмерно длинной query string, ошибочным использованием GET вместо POST, циклическим redirect или генерацией URL, в который приложение помещает слишком много данных.

В отличие от 413 Content Too Large, 414 относится не к размеру request body, а к адресу запроса.

Что означает HTTP 414

Пример проблемного запроса:

GET /search?filter=...очень_длинный_набор_параметров... HTTP/1.1
Host: example.com

Путь обработки:

клиент
  ↓ длинный URI
CDN/WAF
  ↓
reverse proxy
  ↓
приложение

один из уровней не готов интерпретировать URI
→ 414

RFC 9110 определяет 414 как ответ на URI, который длиннее, чем сервер готов интерпретировать.

414 и 413 — не одно и то же

Например, перенос большого JSON из query string в body может убрать 414, но при слишком большом body уже проявится 413.

См. также: Ошибка 413 Payload Too Large.

Основные причины 414

GET используется для слишком большого объёма данных

Форма или frontend может сериализовать большое состояние в query parameters:

/search?ids=1,2,3,...&filters=...&state=...

Если данные по смыслу являются телом операции, GET может быть выбран неправильно.

Циклический redirect наращивает URL

Ошибка конфигурации способна на каждом redirect добавлять новый prefix или параметр:

/a
→ /redirect?next=/a
→ /redirect?next=/redirect?next=/a
→ ...

URI растёт, пока не достигает лимита.

URL содержит закодированное состояние

JWT, длинные base64-строки, сериализованные фильтры или tracking parameters могут сильно раздувать адрес.

Проблема возникает только на одном уровне

CDN, WAF, reverse proxy и application server могут иметь разные ограничения. Поэтому одинаковый backend может работать напрямую, но получать 414 через публичный gateway.

Шаг 1. Зафиксируйте фактическую длину URL

Не оценивайте «на глаз». Сохраните точный URL и измерьте его.

Например, в shell:

url='https://example.com/search?...'
printf '%s' "$url" | wc -c

Измерение в байтах особенно важно, если URL содержит percent-encoding.

Шаг 2. Посмотрите redirect chain

curl -I https://example.com/path

Для просмотра переходов:

curl -IL --max-redirs 10 https://example.com/path

Если каждый Location становится длиннее предыдущего, ищите ошибку redirect rule.

Не повышайте --max-redirs бесконечно: задача диагностики — увидеть цикл, а не пройти его любой ценой.

Шаг 3. Сократите query string

Сравните:

короткий URL → 200
средний URL  → 200
длинный URL  → 414

Если граница воспроизводится стабильно, проблема действительно связана с длиной URI.

Шаг 4. Определите компонент ответа

Проверьте цепочку:

client → CDN/WAF → load balancer → Nginx → app

Полезные признаки:

• response headers;
• server header;
• branded error page;
• access log;
• наличие запроса в application log;
• request ID.

Если приложение не видит запрос, ограничение сработало раньше.

Шаг 5. Проверьте модель API

Не переносите чувствительные или объёмные данные в URL только ради обхода body parsing.

URI попадает в:

• browser history;
• access logs;
• proxy logs;
• analytics;
• referrer-related механизмы;
• кеш-ключи.

Секреты, токены и персональные данные не должны оказываться в query string без строгой необходимости.

Если операция передаёт сложную структуру, часто лучше использовать body с подходящим методом и Content-Type.

Шаг 6. Проверьте frontend и форму

Классический источник 414 — форма с method="get", которая отправляет большой текст как query string.

Проверьте:

<form method="get">

Если операция не является поиском/навигацией и передаёт большой payload, возможно, нужен другой HTTP-контракт.

414 после релиза

Ищите изменения:

1. новые tracking parameters;
2. сериализация state в URL;
3. новый redirect;
4. изменение route prefix;
5. переход GET/POST;
6. новый CDN/WAF;
7. изменение proxy limits.

Если URL стал длиннее ровно после frontend-релиза, инфраструктурный лимит мог просто проявить ошибку клиентского дизайна.

Как проверить исправление

Проверяйте не только URL, который раньше падал:

обычный URL → ожидаемый ответ
длинный допустимый URL → ожидаемый ответ
аномально длинный URL → контролируемый 414 или иной заданный защитный ответ
redirect chain → не растёт

Если после исправления система принимает URI практически неограниченной длины, вы могли снять защиту вместо устранения причины.

Автоматическое обнаружение

Для обычного мониторинга не нужно регулярно генерировать экстремально длинный URL. Но критичный endpoint можно проверять с реалистичным набором query parameters, чтобы обнаружить поломку маршрута или неожиданное изменение публичного proxy.

UpWatch можно использовать для HTTP-проверки критичного URL с фиксированными параметрами и ожидаемым статусом.

Типичные ошибки

• путать 414 и 413;
• просто увеличивать лимит URI;
• не проверять redirect loop;
• помещать большие структуры в query string;
• отправлять секреты через URL;
• анализировать только приложение, когда запрос блокирует CDN;
• измерять длину исходной строки, игнорируя percent-encoding.

Практический чек-лист

1. Подтвердить HTTP 414.
2. Сохранить точный URL.
3. Измерить длину URI.
4. Проверить redirect chain.
5. Сократить query string и найти границу.
6. Определить компонент ответа.
7. Проверить GET/POST design.
8. Проверить tracking и serialized state.
9. Проверить proxy/CDN/WAF.
10. Устранить причину роста URI.
11. Проверить нормальный и граничный сценарии.
12. Убедиться, что redirect больше не увеличивает URL.

Источники и спецификации

• RFC 9110: 414 URI Too Long
• MDN: 414 URI Too Long
• curl: официальная документация