# Предел на размер и число заголовков доставки

- **Секция:** ядро
- **Зачем:** MaxHeaderBytes не задан, в базу заголовки пишутся целиком: дефект спит до деплоя, а просыпается вместе с ним
- **Теги:** goal:limits-and-load

У тела доставки предел есть (`max_body`), у заголовков — нет ни одного:
`MaxHeaderBytes` серверу не задан, а `delivery.headers` пишутся в базу целиком,
сколько бы их ни пришло. В лог они с недавних пор обрезаются, в базу — нет.

Сегодня отправитель один и он свой, поэтому дефект спит. Просыпается он
**вместе с [деплоем](deploy-rivendell.md)**: у приёма, торчащего наружу,
отправитель перестаёт быть своим по определению. Оценка сверху при доставке раз
в пять минут — сотни мегабайт в сутки в таблице, которую никто не подчищает; а
растёт вместе с ней и стоимость пересборки, которая учёт материализует целиком.

Чинится дёшево и в двух местах сразу: `MaxHeaderBytes` у `http.Server` и предел
на то, что уходит в колонку. Разумно делать одной правкой с
[управлением токенами](token-and-secret-management.md) — оба пункта про одно и то же:
приём перестаёт доверять тому, кто с ним говорит.

Осторожно: это путь приёма, а доставка, не попавшая в архив, теряется навсегда.
Отказ по превышению обязан наступать **до** записи тела, а не после, и быть
отличим в логе от отказа обстоятельств.

Готово, когда доставка с заведомо раздутыми заголовками получает внятный отказ,
не оставляя следа в базе, а обычная доставка проходит как раньше.

Связано: `internal/httpapi`, `internal/ingest`, `docs/architecture.md` → «Приём».