Forward Proxy Streaming vs. Full-Response Buffering

When a download appears to wait, separate three events: response headers arrive, body bytes arrive, and the application can use or render the result. A spinner alone cannot identify which one is delayed.

The normal streaming stages can overlap:

origin produces a chunk → proxy forwards bytes → client consumes them

A proxy can write eligible content to cache while relaying it. Caching does not require waiting for the whole file. Squid's read_ahead_gap controls retrieval running ahead of delivery, which is another kind of buffering.

Backpressure can temporarily stop upstream reads when a slow client fills output queues. Content-Length also supplies length without requiring full buffering. HTTP/1.1 chunked coding permits incremental delivery but cannot promise low latency if an earlier component holds the data.

Inspect processing stages next. Rewriting or inspection may need part or all of a body. Compression and application framing can delay useful output. On the client, a complete-byte-array method waits before returning, and a browser may receive bytes before it can render them.

After successful CONNECT, an ordinary proxy relays the service stream without needing the tunneled file's final length. Follow the first missing event above before changing its buffer or timeout settings. When curl is the observer, its no-buffer option changes the local output stage.