Web cache

Web caching reduces network traffic by storing copies of responses in a cache and serving them for subsequent identical requests. The core principle is that a cache can serve a stored response if it is still fresh, avoiding the need to contact the origin server.¹ This dramatically lowers latency and bandwidth consumption for both users and providers. The effectiveness of a cache is measured by its hit ratio—the percentage of requests served from cache. Modern web caches rely on HTTP caching directives defined in RFC 7234, which specify freshness lifetimes and validation mechanisms.² Caches can be located on the client (browser cache), on intermediate network nodes (proxy caches), or on the server side (reverse proxy caches).

Browser caches store resources locally on a user's device, making repeat visits faster. Proxy caches, often deployed by ISPs or organizations, serve multiple users and can reduce upstream bandwidth. Content delivery networks (CDNs) operate large distributed caches that bring content closer to users geographically.³ Reverse proxy caches sit in front of origin servers and offload traffic by caching responses. A less common variant is the transparent proxy cache, which intercepts HTTP traffic without explicit client configuration. Each type has different cache freshness and invalidation policies, and they can be layered for maximum efficiency.

HTTP headers control caching behaviour. Cache-Control directives (e.g., max-age, no-cache, private) define freshness and scope. Expires provides an absolute expiry time. For validation, ETag (entity tag) allows conditional requests: the client sends the tag, and the server responds with 304 Not Modified if the resource is unchanged.¹ Last-Modified works similarly with timestamps. The Vary header is critical for content negotiation, instructing caches to store multiple versions based on request headers like Accept-Encoding or User-Agent.² Misconfigured Vary can cause cache bloat or serve incorrect content.

Cache invalidation removes stale entries. The primary mechanism is time-to-live (TTL), set via max-age or Expires. When a resource changes before its TTL expires, the server must forcefully invalidate the cache—often through a purge request or by using a versioned URL (cache busting). Edge cases include shared caches that must respect the private directive to avoid leaking user-specific data. Another challenge is the stale-while-revalidate directive, which allows serving stale content while asynchronously fetching a fresh copy. Web caches also handle no-store resources by never caching them, which is common for sensitive data.

Web cache poisoning occurs when an attacker injects a malicious response into a cache, causing subsequent users to receive harmful content. This attack exploits discrepancies in how origin servers and caches parse headers or URLs.⁴ Web cache deception, by contrast, tricks a cache into storing private data by making it look like a static resource. Another subtlety is cache key selection: a cache uses the URL and sometimes the Host header as the key, but variations in query parameter order or encoding can lead to unnecessary misses or collisions. The Vary header with wildcards (Vary: *) effectively disables caching for that resource. Additionally, dynamic content that changes frequently (e.g., real-time stock prices) can be cached for very short periods using max-age=0 combined with stale-while-revalidate to balance freshness and load.

Shared caches (e.g., proxy caches) pose privacy risks because they can serve cached responses containing sensitive user data to other users if not properly isolated. The Cache-Control: private directive prevents this, but misconfiguration or missing headers can expose information.⁵ Cache-based side-channel attacks, such as those exploiting timing differences between cache hits and misses, can leak information across browser contexts. Secure cookies should be marked with the SameSite attribute and not cached by proxies. Furthermore, HTTPS traffic is often not cached at intermediate proxies, but encrypted content may still be cached at the client or within a CDN if the origin allows it. Developers must carefully set caching headers to balance performance with security.

Cache hit

A request that is served from the cache without contacting the origin server.

Cache miss

A request that is not found in the cache and must be fetched from the origin server.

TTL (Time to Live)

The maximum time a cached resource can be stored without revalidation, usually set via the <code>max-age</code> directive.

ETag

An opaque identifier assigned by the server to a specific version of a resource, used for conditional requests.

Cache busting

A technique that forces a new copy of a resource to be loaded by changing its URL (e.g., appending a version number) when the content changes.