cache_v2: implement max_body_bytes using response Content-Length

cache_v2: implement max_body_bytes using response Content-Length

Background

We run Envoy cache v2 on machines with about 1 TB of local disk available for cache.

Some upstreams also serve very large static files, for example AI training datasets that can be larger than 100 GB. These responses are cacheable today, so a small number of large files can consume most of the available cache space or fill the disk.

CacheV2Config.max_body_bytes already exists (0 means unlimited), but is currently marked as unimplemented.

It would be useful to support a simple size limit so these large static files can still be served from upstream without being inserted into the cache.

Proposed behavior

For responses with a known Content-Length:

• If max_body_bytes == 0, keep the current behavior.
• If Content-Length > max_body_bytes, serve the upstream response normally but do not insert it into the cache.
• Otherwise, cache the response as usual.

If Content-Length is not available, the current behavior would remain unchanged.

This means the limit would mainly address large static files whose size is known before the body is streamed.

Implementation idea

One possible approach would be to check max_body_bytes in CacheSession::onUpstreamHeaders, after the response has passed the existing cacheability checks and the Content-Length is available.

If the response exceeds the configured limit, it may be possible to reuse the existing onUncacheable path so that the upstream response is still delivered to the client without starting a cache insert.

max_body_bytes would also need to be read from CacheV2Config, since it is not currently used by the implementation.

I would appreciate feedback on whether this is the right place and behavior for the check, or whether there is a better way to integrate it with the current cache insertion flow.

Limitations

This would not provide a strict body-size limit for every response.

The proposed check only works when the response provides a usable Content-Length. Responses whose final size is only known while streaming would still be cached, for example:

• HTTP/1.1 responses using Transfer-Encoding: chunked
• responses where compression or transfer handling means the final body size is not known from Content-Length
• HTTP/2 or HTTP/3 responses without Content-Length
• other streaming responses without a known body size

Supporting these cases would require tracking the number of body bytes during insertion and stopping or rolling back an insert after it has already started. That would be a significantly larger change to the cache insertion path.

For the current use case, the goal is narrower: prevent very large static files with a known Content-Length from consuming the local cache.