Streaming seems ineffective with `process_response`?

[TomStrepsil]

Firstly, thanks for open sourcing this project, and great news on the Akamai-parity with the latest update.

I'm having some difficulty achieving streaming with a local Viceroy harness.

The docs suggest (under "Streaming Processing (recommended)")

// Stream the ESI response directly to the client
     processor.process_response(

Yet the process_response function appears to buffer everything:

pub fn process_response(
    mut self,
    src_stream: &mut Response,
    client_response_metadata: Option<Response>,
    dispatch_fragment_request: Option<&FragmentRequestDispatcher>,
    process_fragment_response: Option<&FragmentResponseProcessor>,
) -> Result<()> {
    let mut output = Vec::new();          // ← buffers into Vec
    self.process_stream(
        src_stream.take_body(),
        &mut output,                      // ← writes to Vec, not client
        dispatch_fragment_request,
        process_fragment_response,
    )?;
    // ... apply cache headers, $add_header, $set_response_code, $set_redirect ...
    resp.set_body(body_bytes.as_ref());
    resp.send_to_client();                // ← sends buffered body at the end
    Ok(())
}

...presumably to support the potential for response manipulation functions (as mentioned in the docs)?

Is there a way to get process_response to stream output?

[vagetman]

Thanks for sending those. I’ll get back to you on all them soon. Just want to ack the reception. Good timing too as I was going to push another update. So, if anything needs a change it will be rather a quick turnaround. Stay tuned.

[vagetman]

In short, the docs calling process_response() "streaming" is a bit misleading. It streams the input parsing but buffers the output.

Why it's done this way: process_response() needs to apply response metadata after processing - headers from $add_header(), status from $set_response_code(), body override from $set_response_code(code, body), redirect from $set_redirect(). Since Fastly's Response::send_to_client() sends headers + body together, the body must be fully assembled first to know the final headers/status.

For true end-to-end streaming, users need to call process_stream() with a StreamingBody as the writer, accepting the trade-off that response headers are locked in before ESI processing begins.

Having said that, I think it makes sense to add process_response_streaming() that would allow to the true streaming for cases where there are no metadata updates.

[vagetman]

@TomStrepsil please try beta-4 that has commits from #47 and confirm the issue is fixed?

[TomStrepsil]

As per here - I don't seem to be getting streaming behaviour with process_response_streaming