Streaming pipeline chunk-emitting

[aram356]

Summary

This PR lands the full streaming-response optimization for the publisher proxy, reducing peak WASM memory from ~4× response size to constant and improving TTFB/TTLB on every processable origin response. It replaces the original "buffer everything, rewrite, send" path with a chunked pipeline that streams through the content rewriters and writes directly to the client.

Delivered across four phases (plus follow-up review cycles):

Phase 1 — Chunk-emitting pipeline (streaming_processor.rs)

• Unified StreamingPipeline<R: Read, W: Write> with a single process_chunks loop that handles uncompressed, gzip↔gzip, gzip→none, deflate↔deflate, deflate→none, brotli↔brotli, and brotli→none, including explicit per-codec finalization semantics (finish() for flate2, flush() + into_inner() for brotli).
• HtmlRewriterAdapter wraps lol_html::HtmlRewriter as a StreamProcessor that drains output after every chunk via a shared Rc<RefCell<Vec<u8>>> sink, so lol_html buffering no longer dictates allocation size.
• Compression imports hoisted to module scope to satisfy the repo's no-local-imports convention.

Phase 2 — Stream to client via StreamingBody (publisher.rs, adapter main.rs)

• handle_publisher_request returns a PublisherResponse sum type (Stream / PassThrough / Buffered) instead of a single Response, so the adapter picks the right Fastly dispatch (stream_to_client() / send_to_client() / return-and-send).
• The Fastly adapter moved from #[fastly::main] to an undecorated main() with Request::from_client() — #[fastly::main] auto-sends the returned response and is incompatible with streaming.
• process_response_streaming became generic over W: Write, so the same function writes into a Vec<u8> on the buffered route and a StreamingBody on the streaming route. Content-Length is removed on the streaming arm (chunked transfer).
• restrict_accept_encoding (quality-value-aware) strips unsupported encodings from Accept-Encoding before proxying, so the origin never responds with a codec the pipeline cannot decode.

Phase 3 — Fragment-safe script rewriters (google_tag_manager.rs, nextjs/script_rewriter.rs, nextjs/rsc_placeholders.rs)

• With streaming input, lol_html now fragments <script> text nodes at chunk boundaries. NextJsNextDataRewriter and GoogleTagManagerIntegration accumulate intermediate fragments into a Mutex<String> buffer, suppress them via RemoveNode, and emit the full rewritten text on is_last_in_text_node. The Mutex is uncontended (the pipeline is single-threaded; lol_html::HtmlRewriter is !Send) and is documented with the invariant that the buffer is empty at the start of every text node.
• NextJsRscPlaceholderRewriter deliberately does not accumulate — the accompanying NextJsHtmlPostProcessor re-parses the final document, so fragmented RSC scripts are safely deferred. Accumulating here would risk corrupting non-RSC scripts that happen to be fragmented.
• GTM uses a script selector that matches every inline script. To prevent GTM's final Replace(accumulated) from overwriting an earlier NextJsNextDataRewriter::Replace on the same element (lol_html runs overlapping text! handlers sequentially; last text.replace wins), GTM only engages its accumulation path when the running text contains a GTM/GA marker or ends with a proper prefix of one of length ≥ 6 bytes ("google" — the common prefix of googletagmanager.com and google-analytics.com). Shorter tails (g, go, goo, goog, googl, plus common English/minified tokens like img, slug, config, thing) no longer claim ownership, so overlapping rewriters are preserved.
• HtmlWithPostProcessing bifurcates: when no post-processors are registered, chunks pass through immediately (the streaming win); when post-processors are registered, output accumulates in an internal buffer until is_last, then post-processors run on the full document. Uses IntegrationRegistry::has_html_post_processors() (new, avoids cloning the Arc vec).

Phase 4 — Binary pass-through via send_to_client() (publisher.rs)

• Non-processable 2xx responses (images, fonts, video) return PublisherResponse::PassThrough { response, body }. The adapter reattaches the body and calls send_to_client(), preserving Content-Length and avoiding chunked-encoding overhead. Fastly streams the body from its internal buffer without copying into WASM memory.
• 204 No Content and 205 Reset Content are excluded at the top of the classifier (RFC 9110 §15.3.5 / §15.3.6 prohibit a message body) so no downstream arm can emit a body for a status that must not have one.

Routing classifier (classify_response_route)

• Pure function driving the PublisherResponse selection from (status, content_type, content_encoding, request_host, has_post_processors). Four outcomes:
  • PassThrough — 2xx non-processable.
  • Stream — processable content (2xx and non-2xx — branded 404/500 HTML and error JSON still get origin URL rewriting, matching pre-streaming behavior) with supported encoding and either non-HTML or no HTML post-processors.
  • BufferedProcessed — HTML with post-processors registered (full document needed for injection).
  • BufferedUnmodified — 204/205, empty request host with processable content (misconfig warning), or unsupported Content-Encoding.

Unsupported encodings and accept-encoding restriction

• is_supported_content_encoding (known-list gate on ""/identity/gzip/deflate/br) routes unsupported codecs (e.g. zstd) to BufferedUnmodified rather than feeding encoded bytes to the identity decoder.

Files touched

 crates/trusted-server-adapter-fastly/src/main.rs   |   85 +-
 crates/trusted-server-core/src/html_processor.rs   |  198 +++-
 .../src/integrations/google_tag_manager.rs         |  503 ++++++++-
 .../src/integrations/nextjs/mod.rs                 |   51 +
 .../src/integrations/nextjs/rsc_placeholders.rs    |   11 +-
 .../src/integrations/nextjs/script_rewriter.rs     |  154 ++-
 .../src/integrations/registry.rs                   |    9 +
 crates/trusted-server-core/src/publisher.rs        |  824 +++++++++++---
 .../trusted-server-core/src/streaming_processor.rs |  867 +++++++++------
 docs/superpowers/plans/2026-03-25-streaming-response.md
 docs/superpowers/specs/2026-03-25-streaming-response-design.md
 (+ CI pin cleanup from #656 reflected via main merge)

Test plan

Shipped in this PR (all green under cargo test --workspace, cargo clippy --workspace --all-targets --all-features -- -D warnings, cargo fmt --all -- --check):

• Pipeline codecs: uncompressed, gzip↔gzip, gzip→none, deflate↔deflate, brotli↔brotli round-trip tests; every compressed-output test decompresses and asserts bytes, proving encoder finalization.
• Chunk-boundary fragmentation invariant: lol_html_fragments_text_across_chunk_boundaries verifies lol_html splits text at chunk boundaries (the assumption all fragment-safe rewriters rely on).
• HtmlRewriterAdapter: streams per chunk, handles large input, tolerates reset() as a no-op, and emits output before is_last.
• Classifier: 14 gate tests covering every (status, content-type, encoding, host, post-processors) combination, including 204/205 exclusion for processable content, non-2xx processable streaming, and unsupported-encoding fallback.
• Fragment-safe rewriters: unit tests for NextJsNextDataRewriter accumulation, no-URL passthrough, and GTM's prefix gate (might_contain_gtm_prefix_detects_full_match_and_boundary_prefix, might_contain_gtm_prefix_rejects_short_ambiguous_tails). End-to-end tests with chunk_size=32 (small_chunk_next_data_rewrite_survives_fragmentation, small_chunk_gtm_rewrite_survives_fragmentation) force fragmentation through the full HTML pipeline.
• Overlap regressions: fragmented_next_data_survives_with_gtm_enabled and fragmented_next_data_with_trailing_g_survives_gtm (this latter exercises the short-g-tail overlap case from review P1) confirm NextJs rewrites are not clobbered by GTM on the same fragmented element.
• Pass-through: classifier coverage for every 2xx non-processable path plus pass_through_preserves_body_and_content_length proving byte-for-byte identity.
• stream_publisher_body end-to-end: gzip CSS round-trip with origin rewriting.
• Accept-Encoding restriction: absent header, unsupported-only (zstd), identity-only, quality-value handling (br, gzip;q=0).
• EC header + consent handling on the streaming path: headers set before body consumption; revocation targets cookie EC ID not header EC ID.

Coverage gaps from the initial audit now closed (commit ebbfae7):

• small_chunk_rsc_push_survives_fragmentation_via_post_processor_fallback — fragmented __next_f.push through the post-processor fallback (also the path suspected in the autoblog parse error).
• stream_publisher_body_handles_empty_body — empty origin body on the streaming route.
• stream_publisher_body_surfaces_mid_stream_decode_error — mid-stream decode error must return Err so the adapter can drop the StreamingBody instead of emitting malformed output.
• publisher_response_pass_through_reattach_preserves_bytes — walks the adapter's take-body/reattach pattern explicitly.
• buffered_processed_sets_content_length_from_processed_body — asserts the classifier → pipeline composition for HTML + post-processor.
• document_state_placeholders_substitute_through_accumulating_path — IntegrationDocumentState written during streaming is read and consumed by the post-processor.

Test totals: 848 workspace tests, all green. Clippy + fmt clean.

Rollout

• Classifier is conservative by default: any unfamiliar encoding, any HTML with post-processors, or any misconfigured Host falls back to the unchanged buffered path. Only pages that meet all streaming preconditions take the new code path.
• No public API changes to IntegrationRegistration, routes, or settings. IntegrationRegistry::has_html_post_processors() is a new additive method.
• Closes Create spec and plan for streaming response for non-Next.js publisher proxy #565. Addresses review feedback from Phase 2: Stream responses to client via StreamingBody #585, Phase 3: Make script rewriters fragment-safe for streaming #591, Phase 4: Stream binary pass-through responses via send_to_client() #594, Implement generic Prebid bid param override rules #618.

[ChristianPavilonis]

Second pass review. Previous comments were addressed — has_html_post_processors() is implemented.

Previous comments resolved: Both prior inline comments are addressed — the has_html_post_processors() optimization is present in registry.rs and the streaming plan doc was updated.

New findings:

1. Doc comment copy-paste in HtmlRewriterAdapter::reset() (commented inline). Minor, but renders incorrect in rustdoc.

2. Gate tests validate boolean expressions, not function behavior (commented inline). The streaming_gate_* and pass_through_gate_* tests reproduce the conditional logic from handle_publisher_request as local variables and assert on those variables. They pass even if the gate in the actual function is changed. The unsupported_encoding_response_is_returned_unmodified test (which uses a real Response) is the right model — the gate tests should follow that pattern using handle_publisher_request returning a PublisherResponse variant.

3. Missing WARN log when processable content is skipped due to empty request host (commented inline). The combined condition !should_process || request_host.is_empty() || !is_success logs at DEBUG for all three cases. An empty request_host with processable content is a misconfiguration that silently returns unrewritten HTML/JS to the client. Worth a separate warn branch.

No blocking issues. The core streaming architecture — chunk-emitting HtmlRewriterAdapter, unified process_chunks loop, PublisherResponse enum, and the pass-through/stream/buffered routing in main.rs — is sound. The Mutex accumulation buffers in GTM and NextJS rewriters are correctly drained on the final fragment path. The brotli encoder finalization via flush() inside process_chunks followed by into_inner() is correct. Content-Length handling is consistent across all three response paths.

[ChristianPavilonis]

Findings from second pass are non-blocking — approving.

[prk-Jr]

👍 Looks good