Skip to main content
Accelerators groups the two sections that speed up repeat access: Caching stores responses in memory for reuse, and Prefetch proactively downloads resources before a client requests them. They interact — a prefetched object is only useful if Caching later serves it — so both live on this one page.
The Cache section controls in-memory HTTP caching, refresh policy, and ICP parameters for forwarding.

Cache read path

Core mechanics

Refresh — first match wins

Walk Refresh rows top-down; first enabled row whose profiles match sets min/max age, validate, and cachable flag, then stops. cachable=FALSE sets CACHE_INVALID unless CACHE_FORCE.
Disk store is hard-disabled. Disk store selection is inactive — new objects are memory-only regardless of Store row configuration.

Violate RFC

Objects stored despite no-cache / no-store get CACHE_VIOLATION. When Violate RFC is off, reads return NULL (not served). When on, violation objects may be served.

Examples

Open Configure → Application Setup → Accelerators → Caching → Refresh. Row fields are Enabled, Comment, Profiles, Cachable, Minimum/Maximum age, Revalidate age, and Last-Modified time factor.

Caching — Refresh rows

Uncachable profile on top

Config: Refresh row 1 profiles uncachable, cachable off; row 2 blank profiles, cachable on.Result: Tagged connections get CACHE_INVALID on new entries; others use row 2 ages.

Violate RFC off

Config: violaterfc false; stored no-store object.Result: Second client does not receive object from cache — miss to origin.

Store row present

Config: Store enabled with path and quota.Result: select_store still NULL — memory-only in current builds.

How to verify

  1. Enable CACHE in LOG_LEVEL.
  2. Repeat URL request; check Detailed logs for hit/miss.
  3. Use Manage cached objects to inspect or purge entries.