Gatling 3.7.0 HTTP Caching: Uncertain Cache Invalidation Behavior with Proxies

Goal

Investigate how Gatling 3.7.0’s in‑memory HTTP cache responds to Cache‑Control directives when the responses traverse a reverse proxy that rewrites or drops headers.

Constraints

The cache is per‑host, limited by a configurable size, and invalidation is triggered only via the clearCache method. Proxies can modify Cache‑Control, ETag, or add Age, potentially masking the tool’s own caching logic.

Unresolved Decision

It remains unclear whether clearing the cache respects the host‑specific size limit, how the must‑revalidate directive is enforced after a proxy removes ETag, and whether additional configuration is needed to preserve cache semantics in such environments.

Questions

• When clearCache is called, does the cache reset the per‑host size counter or only the stored entries?
• If a reverse proxy strips ETag but keeps Cache‑Control: must‑revalidate, does Gatling still treat the cached response as fresh until the next request?
• Is there a configuration knob to instruct Gatling to honor proxy‑modified Cache‑Control headers rather than the original response headers?