- каждая запись каталога задач получила тип вместо тега kind: и префикса заголовка; секция роадмапа «Разработка» стала «Сопровождением», порядок секций канонический - поправлены протухшие факты: нереализованные маршруты Read API, MCP и `healthlog import`, словарь слоёв в инварианте, семантика гейта по покрытию диффа, периметр перестал дублировать security.md - замер слияния переведён с находки 49 на находку 54, заполнены Purpose спек storage и parsing
2.7 KiB
✨ Ограничить размер и число заголовков доставки
- Тип: feature
- Категория: Ядро
- Зачем: MaxHeaderBytes не задан, в базу заголовки пишутся целиком: дефект спит до деплоя, а просыпается вместе с ним
- Теги: goal:limits-and-load
У тела доставки предел есть (max_body), у заголовков — нет ни одного:
MaxHeaderBytes серверу не задан, а delivery.headers пишутся в базу целиком,
сколько бы их ни пришло. В лог они с недавних пор обрезаются, в базу — нет.
Сегодня отправитель один и он свой, поэтому дефект спит. Просыпается он вместе с деплоем: у приёма, торчащего наружу, отправитель перестаёт быть своим по определению. Оценка сверху при доставке раз в пять минут — сотни мегабайт в сутки в таблице, которую никто не подчищает; а растёт вместе с ней и стоимость пересборки, которая учёт материализует целиком.
Чинится дёшево и в двух местах сразу: MaxHeaderBytes у http.Server и предел
на то, что уходит в колонку. Разумно делать одной правкой с
управлением токенами — оба пункта про одно и то же:
приём перестаёт доверять тому, кто с ним говорит.
Осторожно: это путь приёма, а доставка, не попавшая в архив, теряется навсегда. Отказ по превышению обязан наступать до записи тела, а не после, и быть отличим в логе от отказа обстоятельств.
Готово, когда доставка с заведомо раздутыми заголовками получает внятный отказ, не оставляя следа в базе, а обычная доставка проходит как раньше.
Связано: internal/httpapi, internal/ingest, docs/architecture.md → «Приём».
Двигает строку «Завершения» цели: «У заголовков доставки есть названный предел».