<h2 id="content"><a href="#content" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Content</h2>
<ul>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#managing-different-responses">Managing different responses</a>
<ol>
<li><a href="#1-personalized-responses">Personalized Responses</a></li>
<li><a href="#2-sensitive-responses">Sensitive Responses</a></li>
<li><a href="#3-get-the-latest-response-every-request">Get the latest response (every request)</a></li>
<li><a href="#4-static-responses">Static Responses</a></li>
<li><a href="#5-cacheable-responses">Cacheable Responses</a></li>
</ol>
</li>
<li><a href="#conclusion">Conclusion</a></li>
</ul>
<h2 id="introduction"><a href="#introduction" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Introduction</h2>
<p>In my previous article, <a href="https://www.jerrychang.ca/writing/http-caching-the-6-core-concepts" target="_blank" rel="nofollow noopener noreferrer">HTTP caching: 6 Core Concepts</a>, I covered the foundations of HTTP caching and how it works.</p>
<p>However, it may still be difficult to know when to use the various directives.</p>
<p>It’s great to learn these concepts but how do we put all that into practice ?</p>
<p>That’s what we’re going to go through in this guide.</p>
<p>When building software applications, you will inevitably have to make considerations in how you manage different types of responses (or data).</p>
<p>This is especially true when it comes to deciding which responses can be cached.</p>
<p><strong>The responses tend to fall into these categories:</strong></p>
<ol>
<li>
<p>personalized responses</p>
</li>
<li>
<p>sensitive responses</p>
</li>
<li>
<p>get the latest response (every request)</p>
</li>
<li>
<p>static responses</p>
</li>
<li>
<p>cacheable responses</p>
</li>
</ol>
<p><strong>Note:</strong> This is not an exhaustive list but some of the common ones</p>
<p>The way you manage the caching for each of these responses are also going to be different.</p>
<p>In terms of HTTP caching, that means we need to provide the proper instructions to the cache on how to manage the responses.</p>
<p>The way you do this is by altering the <strong>Cache-Control</strong> directives.</p>
<p>Let’s go through them one-by-one.</p>
<h2 id="managing-different-responses"><a href="#managing-different-responses" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Managing different responses</h2>
<h3 id="1-personalized-responses"><a href="#1-personalized-responses" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>1. Personalized responses</h3>
<p>When working with personalized responses, meaning this response is only intended for the client making the request, the obvious way to manage this is to <strong>not cache</strong> this response in our shared cache.</p>
<p>We don’t want to share this across the clients, but it is ok to store this on the client (browser cache).</p>
<p>The way we instruct our shared cache to not store this response is using this directive:</p>
<div class="remark-highlight"><pre class="language-sh"><code>Cache-Control: private
</code></pre></div>
<p><strong>What this translate to:</strong> This request should only be cached on the client cache (browser cache), and no where else</p>
<p>That also means all other shared caches should acknowledge this.</p>
<p><strong>Example:</strong> User ID, analytics campaign id, user themes, client app configurations</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-response-private.png" alt="HTTP caching with Cache-Control: private" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>HTTP caching with <b>Cache-Control: private</b></i></blockquote>
  </div>
</div>
<h3 id="2-sensitive-responses"><a href="#2-sensitive-responses" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>2. Sensitive responses</h3>
<p>When working with sensitive responses, or response that is intended only for the client, and it is sensitive (This should not be shared with other people).</p>
<p>It may be tempting to use the <strong>private</strong> directive, however, that still allows it to be cached on the client (browser cache).</p>
<p>When working with a sensitive response, its best we <strong>don’t store this response in any cache at all</strong>.</p>
<p><strong>The directive to use:</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>Cache-Control: no-store
</code></pre></div>
<p><strong>What this translate to:</strong> This response should not be stored in any cache (public or private).</p>
<p><strong>Example:</strong> Banking information, personal information, addresses or any other sensitive information</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-response-sensitive-content.png" alt="HTTP caching with Cache-Control: no-store" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>HTTP caching with <b>Cache-Control: no-store</b></i></blockquote>
  </div>
</div>
<blockquote class="common">
<p><b>💡 Tip: </b> Using <b>Cache-Control: no-store</b> is great for preventing the caches from storing the resource.</p>
<p>However, when using this on a public resource, it can impact the browsing experience because the cache is used in the browser’s back and forward cache.</p>
<p>Use this directive sparingly. Prefer using <b>no-cache</b> and <b>private</b> before considering <b>no-store</b>.</p>
</blockquote>
<h3 id="3-get-the-latest-response-every-request"><a href="#3-get-the-latest-response-every-request" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>3. Get the latest response (every request)</h3>
<p>If you would like the client to always have the latest responses from the server, you’d have to manage the validation request.</p>
<p>Meaning, you need to instruct it to always “check-in” with the server.</p>
<p><strong>The directive to use:</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>Cache-Control: no-cache
</code></pre></div>
<p><strong>Note:</strong> <code class="language-">no-cache
</code> does not mean “do not cache”, the name of it is a little mis-leading</p>
<p><strong>What this translate to:</strong> The cache can still cache this response but it must always validate with the server before serving a response</p>
<p>By doing so, it allows the cache to know if it has the latest response.</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-response-latest-content.png" alt="HTTP caching with Cache-Control: no-cache" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>HTTP caching with <b>Cache-Control: no-cache</b></i></blockquote>
  </div>
</div>
<blockquote class="common">
<b>⚡️ Knowledge Boost: </b> The validation request is the client’s way of “checking-in” with the server to know if the current response is up-to-date.
<p>If you like to learn more about this concept, check out my guide - <a href="https://www.jerrychang.ca/writing/http-caching-the-6-core-concepts#validation" target="_blank" rel="nofollow noopener noreferrer">HTTP Caching: 6 core concepts - validation request</a>.</p>
</blockquote>
<h3 id="4-static-responses"><a href="#4-static-responses" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>4. Static responses</h3>
<p>If you have responses that don’t change over time, then a good way to manage them is to instruct the cache to store them indefinitely.</p>
<p><strong>The directive to use:</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>Cache-Control: immutable
</code></pre></div>
<p><strong>What this translate to:</strong> The cache will not revalidate (or make a validation request) with the server because it will not change.</p>
<p>If you decide to use this directive, be sure that the cached response will not change over time because it may be difficult to invalidate it (or remove it) after the cache is set (especially if it is cached on the browser).</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-caching-immutable-responses.png" alt="HTTP caching immutable responses" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i>HTTP caching with <b>Cache-Control: immutable</b></i></blockquote>
  </div>
</div>
<p>If invalidation is not an option, the alternative is to come up with a cache busting strategy.</p>
<p>For example, you may choose to append a hash id or version number to the file (which most modern frontend bundlers will support).</p>
<h3 id="5-cacheable-responses"><a href="#5-cacheable-responses" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>5. Cacheable responses</h3>
<p>Cacheable are responses that can be stored in the cache.</p>
<p><strong>The directives to use:</strong></p>
<ul>
<li><code class="language-">max-age
</code> (TTL)</li>
<li><code class="language-">public
</code> (can be cached)</li>
<li><code class="language-">s-max-age
</code> (same max-age but specifically for shared cache)</li>
<li>And many more</li>
</ul>
<p><strong>Example (Cache for 60 minutes):</strong></p>
<div class="remark-highlight"><pre class="language-sh"><code>Cache-Control: public, max-age=3600000
</code></pre></div>
<p>There are many combinations you can use when it comes to cacheable responses.</p>
<p>To me, a good way to determine what configuration to use is to understand:</p>
<ul>
<li>how “fresh” do you expect your response to be over time ?</li>
<li>how frequently does it change ?</li>
</ul>
<p>Beyond just caching, you’d also need to decide how the cache should manage responses when they go stale.</p>
<p>This can be done through a <strong>Cache-Control</strong> directive.</p>
<p><strong>Let’s go through the options that we have available.</strong></p>
<h4 id="1-serve-stale-while-revalidating-in-the-background"><a href="#1-serve-stale-while-revalidating-in-the-background" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>1. Serve Stale while revalidating in the background</h4>
<p>In this option, the cache will first serve the stale response.</p>
<p>Then, in the background, the cache will validate the stale response with the server.</p>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-common-use-cases-stale-while-revalidate.png" alt="Managing stale response: stale while revalidate option" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i><b>Managing stale response:</b> stale while revalidate option</i></blockquote>
  </div>
</div>
<h4 id="2-revalidate-then-serve-the-response"><a href="#2-revalidate-then-serve-the-response" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>2. Revalidate then serve the response</h4>
<p>In this option, the cache will first send a validation request to the server before serving the client’s response.</p>
<p>So, that means it will verify with the server to check whether or not the response is still up-to-date.</p>
<p><strong>This can lead to two outcomes:</strong></p>
<ul>
<li>
<p><strong>No change</strong> - Serve the existing response</p>
</li>
<li>
<p><strong>New response available</strong> - Serve the new response</p>
</li>
</ul>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-common-use-cases-must-revalidate.png" alt="Managing stale response: must revalidate option" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i><b>Managing stale response:</b> must revalidate option</i></blockquote>
  </div>
</div>
<h4 id="3-serve-stale-response-if-server-returns-an-error-response"><a href="#3-serve-stale-response-if-server-returns-an-error-response" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>3. Serve stale response if server returns an error response</h4>
<p>This is not directly related to the stale responses but it does still applies.</p>
<p>If during the validation request, the response returns with an error, you can provide the <strong>stale-if-error</strong> directive to instruct the cache to use the stale response in this scenario.</p>
<p><strong>The error codes that this applies to are:</strong> 500, 502, 503 or 504</p>
<p>Here is an example:</p>
<div class="remark-highlight"><pre class="language-sh"><code>Cache-Control: public,max-age=3600000,stale-if-error=1800000
</code></pre></div>
<div style="margin: 2em auto;">
  <div style="display:flex;justify-content:center;">
    <img src="/images/http-common-use-cases-stale-if-error.png" alt="Managing stale response: stale if error option" style="width:80%" />
  </div>
  <div style="display:flex;justify-content:center;">
    <blockquote><i><b>Managing stale response:</b> stale if error option</i></blockquote>
  </div>
</div>
<h2 id="conclusion"><a href="#conclusion" aria-hidden="true" tabindex="-1"><span class="icon icon-link"></span></a>Conclusion</h2>
<p>So, there you you have it, the different ways to handle the common responses in a software application using HTTP Caching.</p>
<p>Let’s do a recap of the response, and how to manage each one using HTTP caching.</p>
<p><strong>Common practical use cases</strong></p>
<ol>
<li>
<p>personalized response - use <strong>Cache-Control: private</strong></p>
</li>
<li>
<p>sensitive response - use <strong>Cache-Control: no-store</strong></p>
</li>
<li>
<p>Get the latest response (every request) - use <strong>Cache-Control: no-cache</strong></p>
</li>
<li>
<p>static response - use <strong>Cache-Control: immutable</strong></p>
</li>
<li>
<p>Cacheable Response - use <strong>Cache-Control: public, max-age=&#x3C;time-in-ms></strong> and decide on how to handle stale response</p>
</li>
</ol>
<ul>
<li>
<p><strong>Common Strategies</strong></p>
<ol>
<li>
<p><strong>stale-while-revalidate</strong> - serve stale response, and revalidate with the server in the background</p>
</li>
<li>
<p><strong>must-revalidate</strong> - revalidate with the server, and either serve stale response or the new response (if it is available)</p>
</li>
<li>
<p><strong>stale-if-error</strong> - allows for re-use of a stale response if error is received from the server (500, 502, 503 or 504)</p>
</li>
</ol>
</li>
</ul>
<p>That’s it! I hope this guide was helpful.</p>
<p>Also, be sure to check out my introduction guide on HTTP caching - <a href="https://www.jerrychang.ca/writing/http-caching-the-6-core-concepts" target="_blank" rel="nofollow noopener noreferrer">HTTP caching: The 6 Core Concepts</a> if you are looking to refresh your knowledge!</p>
<p>If you found this helpful or learned something new, please do share this article with a friend or co-worker 🙏❤️ (Thanks!)</p>


Managing the common responses by using HTTP caching

Jerry Chang

Go Back

HTTP Caching: In-Practice

Enjoy the content ?