Backend Development 19 min read

Understanding HTTP Caching Headers and Their Practical Use

This article provides a comprehensive overview of HTTP caching mechanisms, covering cache‑related header fields, legacy directives like Pragma and Expires, modern Cache‑Control directives, validation headers such as Last‑Modified and ETag, practical simulation with Fiddler, and best‑practice recommendations for both client and server side caching.

Top Architect
Top Architect
Top Architect
Understanding HTTP Caching Headers and Their Practical Use

HTTP caching is a classic interview topic; this article revisits the fundamentals and presents a detailed guide to cache‑related header fields defined in RFC2616.

The 47 cache‑related headers are grouped into four categories: General headers , Request headers , Response headers , and Entity headers , each illustrated with screenshots.

To demonstrate caching behavior, a minimal HTML page containing a local stylesheet and an image is created:

<!DOCTYPE html>
<html>
<head>
  <title>缓存测试</title>
  <link rel="stylesheet" href="css/reset.css">
</head>
<body>
  <h1>哥只是一个标题</h1>
  <p><img src="img/dog.jpg" /></p>
</body>
</html>

Using Fiddler , the article shows how to intercept requests with the bpu localhost command, modify request or response headers, and replay the traffic, enabling the simulation of various caching scenarios.

Browsers often add Cache-Control: max-age=0 on a manual refresh (F5), which forces validation; however, pressing Enter in the address bar does not add this header, allowing cached responses to be used.

Legacy caching directives are covered: Pragma (e.g., <meta http-equiv="Pragma" content="no-cache"> ) and Expires (e.g., <meta http-equiv="expires" content="Mon, 18 Apr 2016 14:30:00 GMT"> ). Their browser support and limitations are discussed.

Cache‑Control is the modern replacement, with directives such as max-age=3600, must-revalidate and combinations like no-cache, no-store for cross‑browser compatibility.

Validation headers are explained: Last‑Modified with If-Modified-Since and If-Unmodified-Since , and ETag with If-None-Match and If-Match . The article details how servers compare these values to decide whether to return 304 Not Modified or the full resource.

In practice, a robust caching strategy combines Expires for older browsers, precise Cache‑Control directives, and enables both ETag and Last‑Modified on the server to maximize cache reuse while ensuring freshness.

Additional headers such as Vary (e.g., Vary: User-Agent, Accept-Encoding ) help proxies store separate cache variants, while Date and Age allow clients to detect whether a response came from a proxy cache.

The article concludes by revisiting the opening question about why Chrome sometimes does not send a validation request on refresh, attributing the behavior to developer‑tools settings, and mentions a JavaScript workaround that dynamically loads resources after the page has loaded.

performanceCachinghttpWeb DevelopmentHeaders
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.