Кратко

  • Incremental: ?1 выражает намерение отправителя для отдельного HTTP-сообщения: начать передачу вниз по пути до получения всего содержимого. Запрос и ответ — разные сообщения, поэтому оба направления обозначаются отдельно.
  • Если посредник понимает поле и полностью отказывается передавать тело постепенно, он обязан вернуть ошибку, а не молча накопить всё сообщение. Несовместимость с проверкой содержимого обозначается 501 и incremental_refused, временный предел параллелизма — 429 и connection_limit_reached.
  • Поле не гарантирует поток на всём пути. Не знающий его узел может буферизовать, а поддерживающий — применять ограничение по времени или байтам. Доказательство связывает направление, распознавание на узлах, политику, пороги, контекст ошибки и измеренную задержку.

В двустороннем обмене клиент ещё отправляет тело, а сервер уже готов вернуть ранний результат. Если прокси ждёт полного запроса или полного ответа, обе стороны могут оказаться в ожидании данных, которые уже существуют, но не переданы. Финальная успешная доставка не исправляет потерянную интерактивность.

RFC 10036 Incremental Forwarding of HTTP Messages вышел в августе 2026 года как предлагаемый стандарт IETF. Авторы — Kazuho Oku, Tommy Pauly и Martin Thomson. В профиле IETF, сохранённом 31 августа, перечислены четыре RFC Oku. Fastly на своей странице называет его Principal OSS Engineer и автором H2O, quicly и picoTLS. Это подтверждает контекст работы над высокопроизводительным сетевым ПО, но не единоличное изобретение или контроль над чужими внедрениями.

Намерение относится к одному сообщению

Incremental — Item из Structured Fields; допустим только Boolean, другой тип игнорируется. ?1 просит постепенную передачу, ?0 явно оставляет обычный режим, где посредник может накопить всё сообщение.

Поле не принадлежит соединению. Отметка в запросе не переносится в ответ. Если приложению нужны оба направления, поле ставится в обоих сообщениях. Поэтому тест ответа ничего не доказывает о постепенной передаче запроса.

Поддерживающий посредник должен отправить секцию заголовков, а затем передавать байты содержимого по мере поступления. Полные заголовки и trailers можно буферизовать. Для настоящих двусторонних протоколов RFC считает Extended CONNECT в целом более согласованным с архитектурой HTTP. Поле не заменяет выбор протокола.

Осознанный отказ нельзя прятать в позднем успехе

Посредник, понимающий поле и решивший не передавать тело постепенно, должен сформировать ошибку. Накопление с последующей доставкой не сохраняет требуемое свойство времени.

На ошибку можно отреагировать: выбрать другой путь или протокол, ограничить функцию, повторить позже, сообщить недоступность. Скрытый буфер оставляет транзакцию внешне здоровой и делает бесполезными консоль, поток событий или ранний ответ.

Правило не объявляет отказом любую задержку и не требует немедленной отправки каждого байта. Оно делает наблюдаемым конкретное решение участвующего узла. Проверка по принципу Running-Code Primacy отправляет различимые фрагменты по реальному пути, измеряет приём и пересылку и воспроизводит отказ, чтобы проверить доставку Proxy-Status.

Постоянная граница проверки и временный предел ёмкости

Некоторым посредникам нужно увидеть всё тело, прежде чем признать его безопасным. Такая проверка несовместима с постепенной доставкой. RFC рекомендует 501 Not Implemented и incremental_refused в Proxy-Status. Без изменения проверки, маршрута, ресурса или протокола повтор почти наверняка не поможет.

Второй случай — ёмкость. Долгие постепенные запросы занимают ресурсы, поэтому посредник может выделить им более строгий пул и защитить обычный трафик. При заполнении рекомендуется 429 Too Many Requests с connection_limit_reached.

Здесь ресурс может быть совместим, но временно нет места. Нужны backoff, приоритет, допуск или расширение. Объединение обоих случаев в «сломанный стриминг» уничтожает различие, которое указывает владельца исправления.

Код статуса без контекста недостаточен: 501 и 429 применяются шире. Требуются Proxy-Status, ответственный узел, ресурс, версия политики и время. Неприсоединившийся посредник остаётся пробелом.

Неизвестный узел может не оставлять следа

Посредник, не знающий поле, не меняет поведение. Неподдерживающий узел тоже может буферизовать. Поэтому отсутствие ошибки не доказывает сквозную поддержку.

Поддерживающий узел, который отказал, прозрачнее неизвестного, который задержал и пропустил. Проверенное предварительное знание помогает на контролируемом пути; иначе RFC предлагает пробовать отдельные ресурсы.

Один домен может иметь разные пути и правила по регионам, типам тела, клиентским классам и нагрузке. Успешная проба подтверждает свои датированные условия, а не выдаёт вечный сертификат поставщику.

Граница полномочий распределена: отправитель выражает намерение; посредник решает вопросы безопасности, ёмкости и передачи; конечная сторона трактует результат. Нельзя обещать за ПО вне своего контроля.

Ограниченный буфер тоже влияет на SLO

Даже поддерживающий узел может накопить небольшое количество данных ради эффективности и защиты от множества мелких пакетов. Возможны пределы по байтам и времени. При достижении любого предела данные нужно передать; держать бесконечно нельзя.

Поэтому поддержка не означает выполнение бюджета первого байта. Порог, незаметный в большом ответе, задержит редкие события. Короткий таймер для человека может быть долгим для машинного контура.

Пороги, класс и загрузка должны иметь версии и связываться с измерением первого байта. Стандарт задаёт Minimum Initial Specification; выбор ресурса, проверка, ёмкость, SLO и fallback остаются локальными решениями.

Собрать квитанцию от пути до результата

Запишите клиент, сервер, ресурс, сборку, ID сообщения и направление. Сохраните значение поля, результат Boolean-разбора, установивший компонент и цель. Для каждого контролируемого или участвующего посредника нужны сегмент протокола, распознавание, правило проверки, политика тела/заголовков/trailers, пределы времени и байтов, пул параллелизма, загрузка и приоритет.

Свяжите HTTP-статус, член Proxy-Status, тип ошибки, ответственный узел, время приёма и отправки первого и последнего байта. Различайте приемлемую постепенную доставку, ухудшение от ограниченного буфера, структурный отказ, временный отказ, вероятную скрытую буферизацию и неубедительные данные.

После этого сохраните решение и владельца: другой маршрут, протокол, повтор, ёмкость, исключение безопасности, сокращённый режим и срок. Содержимое сообщения хранить не нужно; часто достаточно безопасных корреляционных ID, версий политики и времени.

Неизвестный узел, удалённый Proxy-Status или непроверенное направление должны остаться пробелами. Такая честность не позволяет маленькому полю превратиться в выдуманную гарантию.

Источники