bug: bmc-proxy buffers full upstream responses before sending them to the client

[fallintoplace]

Version

main

Describe the bug.

While looking through crates/bmc-proxy/src/bmc_proxy.rs, I noticed the proxy fully buffers the upstream BMC response before returning anything to the downstream client.

The request path has an explicit 8 MiB cap via MAX_BODY_SIZE, but the response path does:

• upstream_response.bytes().await
• then Body::from(body)

So a large Redfish response gets fully materialized in memory before the client sees the first byte. On the BMC proxy hot path that can cause avoidable memory spikes under concurrency, and it also adds latency because the response is not streamed through as it arrives.

I would expect the proxy to stream the upstream response body back to the client, or otherwise enforce an explicit response-size limit if full buffering is required for some reason.

Minimum reproducible example

1. Send a proxied request through carbide-bmc-proxy to a BMC endpoint that returns a large payload.
2. Observe that the proxy waits to read the full upstream body before it starts sending the downstream response body.
3. Under concurrent large responses, memory usage scales with the number and size of in-flight upstream responses.

Relevant log output

No specific runtime log here. This came from reading the current main branch implementation.

Other/Misc.

A few details that made this stand out:

• the request side is capped, but the response side is not
• this behavior appears to date back to the initial authenticated BMC proxy implementation (9001ac23)
• later BMC proxy changes kept the same buffering model, so this looks like an implementation gap rather than a recent regression

Happy to send a follow-up PR to switch this path to streaming if that direction makes sense.