Streaming: HTML post-processor configs buffer the full document until origin EOF

[prk-Jr]

PR #867 streams publisher HTML end-to-end, with one exception: when any IntegrationHtmlPostProcessor is registered (currently the nextjs integration), HtmlWithPostProcessing::process_chunk accumulates all rewriter output and returns nothing until is_last, then runs post-processors on the full document and recompresses. The lazy stream therefore emits zero body bytes until origin EOF for those configurations — even for pages where should_process() would return false. Headers still commit early, but first body byte/FCP tracks the complete origin transfer, so #849's objective is unmet for that configuration.

Why it was deferred in #867

The post-processor path is inherently full-document today. The Next.js placeholder rewriter captures RSC payloads during the streaming lol_html pass and substitutes them at end-of-document, and should_process() consumes either that captured state or the complete document. Making it stream is a design change, not a patch.

Proposed direction

An up-front or streaming should_process gate that decides from request/response metadata (or early document content) whether the page can skip accumulation entirely, so non-RSC pages stream while RSC pages keep the buffered path.

References

• crates/trusted-server-core/src/publisher.rs (PublisherBodyProcessor)
• crates/trusted-server-core/src/html_processor.rs (HtmlWithPostProcessing)
• crates/trusted-server-core/src/integrations/nextjs/html_post_process.rs
• Plan doc Out-of-scope entry: docs/superpowers/plans/2026-07-08-true-origin-streaming-fastly.md
• Prior discussion: Stream publisher origin bodies end-to-end on Fastly #867 review threads (2026-07-13, 2026-07-16)