В этом материале
HTTP framing и прикладной terminal marker проверяются независимо. Корректный JSON в последнем буфере не доказывает полноту ответа.
Потоковый inference API использует несколько вложенных форматов. HTTP передаёт body, SSE выделяет события, а приложение интерпретирует JSON внутри data. Ошибка одного слоя может выглядеть как проблема другого. Например, корректный объект оказался в последнем полученном буфере, но транспорт сообщает неполное сообщение. Тесту нужна раздельная проверка целостности, чтобы не объявлять такое завершение успешным и не обвинять модель без основания.
Определите правила HTTP framing
RFC 9112 описывает framing HTTP/1.1, включая Content-Length, transfer coding и обработку неполных сообщений. Эти правила относятся к транспортному сообщению, а не к числу токенов или SSE-events. Длина body измеряется в bytes, поэтому её нельзя сверять с количеством символов декодированной строки.
Не добавляйте Content-Length наугад к потоку неизвестной заранее длины. И не переносите правила HTTP/1.1 напрямую на HTTP/2: внешний маршрут может менять версию протокола между участками. В отчёте следует назвать исследуемый сегмент, потому что клиентская версия соединения не описывает автоматически upstream path.
Сохраните семантику заголовков
RFC 9110 задаёт общую семантику полей и содержимого HTTP. Важен не только успешный status, но и согласованность сообщения. Если библиотека сообщает framing error, сохраните класс ошибки и доступные безопасные метаданные, а не заменяйте всё сообщением «не удалось разобрать ответ модели».
Тестовый стенд должен контролировать отправленные bytes и закрытие соединения. Используйте локальный fake upstream, а не намеренно повреждайте production-маршрут. Некорректные варианты ограничиваются заранее известным объёмом и сроком, чтобы проверка не превратилась в бесконечное ожидание недостающих данных.
Постройте три контрольных случая
Первый случай передаёт полный body с корректным framing. Второй завершает соединение раньше объявленной длины. Третий содержит завершённый HTTP body, внутри которого отсутствует ожидаемый прикладной итог. Их результат должен различаться: транспортная целостность и полнота генерации отвечают на разные вопросы.
Сохраните исходные заголовки, ожидаемый размер и реально полученный объём. Если клиентская библиотека скрывает часть wire-level деталей, запишите границу наблюдения. Нельзя выдумывать точный серверный механизм только по тому, что пользователь увидел обрыв текста в интерфейсе приложения.
Добавьте SSE поверх корректного транспорта
Стандарт SSE описывает выделение событий из уже получаемого текста. Полное HTTP-сообщение может содержать незавершённое SSE-событие, если отправитель нарушил прикладную форму. Обратная ситуация тоже возможна: некоторые события были полностью доставлены до транспортного сбоя.
У итоговой записи полезны отдельные признаки transport_complete, event_complete и application_complete, если они определены вашей реализацией. Это имена проектного артефакта, а не обязательные поля внешнего API. Они помогают не смешивать частичный полезный текст с полностью завершённой операцией.
Не повторяйте запрос вслепую
Неполная доставка не доказывает, что upstream не выполнил работу. Прежде автоматического повтора нужно учитывать семантику POST и возможность неоднозначного результата. В пределах этого теста достаточно правильно классифицировать исход и сохранить идентификаторы для дальнейшего разбора.
Смежные темы — ошибки stream и сетевая доступность vLLM. Они не заменяют проверку framing: рабочий порт и успешный статус сами по себе не подтверждают целостность транспортного ответа выбранной версии протокола.