беклог: две задачи из разбора разнесения ответа и свёртки
- предел на размер и число заголовков доставки: спит до деплоя - сверка живой витрины с пересборкой: отпечатки печатаются, но сравнивать их некому — известный путь расхождения записан блокером
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
# Предел на размер и число заголовков доставки
|
||||
|
||||
**Приоритет:** средний
|
||||
|
||||
У тела доставки предел есть (`max_body`), у заголовков — нет ни одного:
|
||||
`MaxHeaderBytes` серверу не задан, а `delivery.headers` пишутся в базу целиком,
|
||||
сколько бы их ни пришло. В лог они с недавних пор обрезаются, в базу — нет.
|
||||
|
||||
Сегодня отправитель один и он свой, поэтому дефект спит. Просыпается он
|
||||
**вместе с [деплоем](deploy-rivendell.md)**: у приёма, торчащего наружу,
|
||||
отправитель перестаёт быть своим по определению. Оценка сверху при доставке раз
|
||||
в пять минут — сотни мегабайт в сутки в таблице, которую никто не подчищает; а
|
||||
растёт вместе с ней и стоимость пересборки, которая учёт материализует целиком.
|
||||
|
||||
Чинится дёшево и в двух местах сразу: `MaxHeaderBytes` у `http.Server` и предел
|
||||
на то, что уходит в колонку. Разумно делать одной правкой с
|
||||
[управлением токенами](upravlenie-sekretami.md) — оба пункта про одно и то же:
|
||||
приём перестаёт доверять тому, кто с ним говорит.
|
||||
|
||||
Осторожно: это путь приёма, а доставка, не попавшая в архив, теряется навсегда.
|
||||
Отказ по превышению обязан наступать **до** записи тела, а не после, и быть
|
||||
отличим в логе от отказа обстоятельств.
|
||||
|
||||
Готово, когда доставка с заведомо раздутыми заголовками получает внятный отказ,
|
||||
не оставляя следа в базе, а обычная доставка проходит как раньше.
|
||||
|
||||
Связано: `internal/httpapi`, `internal/ingest`, `docs/architecture.md` → «Приём».
|
||||
Reference in New Issue
Block a user