New Transparent capture is in preview. Record every app's traffic with no proxy configuration, on Windows, macOS and Linux. Learn more

removeCacheAction Action

Remove cache control directives from both request and response headers so every exchange forces a fresh fetch from the origin.

Caching is usually a friend, but during debugging it can mask the real behaviour of an application. removeCacheAction clears the way so every exchange you capture reflects what the upstream service is actually returning right now, not what was returned the last time the client asked.

When to use this action

removeCacheAction is the right pick when caching is hiding the bug. By stripping cache directives from both directions, every request hits the upstream and every response is treated as new by the client.

Useful when:

  • Debugging a release where the browser keeps serving stale assets from disk.
  • Verifying that a CDN actually returns the latest content during a deployment window.
  • Comparing fresh upstream responses across captures without conditional revalidation noise.

Scope it tightly. Removing cache directives across an entire capture session can dramatically increase upstream load and slow down page loads.

Real world examples

Disable cache for a problem CDN host

Force every asset request through to the CDN origin so you can see exactly what is returned, with no 304 Not Modified short cuts.

rules:
- filter:
    typeKind: HostFilter
    pattern: cdn.example.com
  actions:
  - typeKind: RemoveCacheAction

Bypass cache only on specific paths

Keep the rest of the site cached while you investigate a single endpoint that seems to return stale data.

rules:
- filter:
    typeKind: FilterCollection
    operation: And
    children:
    - typeKind: HostFilter
      pattern: app.example.com
    - typeKind: PathFilter
      pattern: ^/static/main\.js
  actions:
  - typeKind: RemoveCacheAction

Force fresh API responses during a release validation

Ensure every API call during a release window goes to the origin without conditional revalidation, so you can compare fresh payloads between deploys.

rules:
- filter:
    typeKind: HostFilter
    pattern: api.internal.example.com
  actions:
  - typeKind: RemoveCacheAction

Reference

removeCacheAction

Description

Remove all cache directive from request and response headers. This will force the clientto ask the latest version of the requested resource.

Evaluation scope

Evaluation scope defines the timing where this filter will be applied.

requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client

YAML configuration name

removeCacheAction

Settings

This action has no specific characteristic

Example of usage

The following examples apply this action to any exchanges

Remove all cache directive from request and response headers. This will force the clientto ask the latest version of the requested resource.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: RemoveCacheAction

.NET reference

View definition of RemoveCacheAction for .NET integration.

See also

This action has no related action

Frequently asked questions

Which headers does this action strip?

Cache related headers such as Cache-Control, Pragma, Expires, ETag, If-None-Match, and If-Modified-Since on both the request and the response. After the action runs, the exchange behaves as if no cache existed.

Does this affect the browser disk cache?

Indirectly. With no cache directives in the response, modern browsers will not store the resource for reuse, so the next request comes back through Fluxzy.

Can I combine it with addResponseHeaderAction?

Yes. Strip the existing directives first and then add an explicit no-store header if you want to enforce a stricter policy on the client side.

Is this safe to run on a high traffic capture?

It increases upstream load because every request bypasses the cache. Scope the filter to the host or path you are investigating to limit the impact.

Learn more about Fluxzy rules