Cache-Control headers in Nginx - Step-by-Step Execution

Process Flow - Cache-Control headers

Client Request

↓

nginx receives request

↓

Check Cache-Control config

↓

Add Cache-Control header to response

↓

Send response with Cache-Control header

↓

Client/browser caches or not based on header

The flow shows how nginx adds Cache-Control headers to HTTP responses, guiding browsers on caching behavior.

Execution Sample

Nginx

location /static/ {
    add_header Cache-Control "public, max-age=3600";
}

This nginx config adds a Cache-Control header to responses for /static/ files, allowing caching for 1 hour.

Process Table

Step	Action	Cache-Control Header Set	Effect on Client Cache
1	Client requests /static/image.png	None yet	No cache info yet
2	nginx matches location /static/	None yet	No cache info yet
3	nginx adds header: Cache-Control: public, max-age=3600	public, max-age=3600	Client can cache for 3600 seconds
4	Response sent to client with header	public, max-age=3600	Client stores response in cache
5	Client requests same resource within 3600s	public, max-age=3600	Client serves from cache, no new request sent
6	Client requests after 3600s	public, max-age=3600	Client sends new request to server
7	Execution ends	N/A	Cache expired, new fetch needed

💡 Cache expires after max-age seconds, client must revalidate or fetch new response

Status Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	After Step 6	Final
Cache-Control Header	None	public, max-age=3600	public, max-age=3600	public, max-age=3600	public, max-age=3600	N/A
Client Cache State	Empty	Empty	Cached response stored	Serving from cache	Cache expired	Empty

Key Moments - 3 Insights

Why does the client serve the cached response without contacting the server between steps 4 and 5?

Because the Cache-Control header with max-age=3600 tells the client the response is fresh for 3600 seconds, so it can use the cached copy without asking the server again (see execution_table step 5).

What happens when the max-age time expires?

After max-age seconds, the client considers the cached response stale and sends a new request to the server to get fresh content (see execution_table step 6).

Does nginx cache the response itself in this example?

No, nginx only adds the Cache-Control header. The caching happens on the client/browser side based on that header.

Visual Quiz - 3 Questions

Look at the execution_table at step 3. What Cache-Control header does nginx add?

A no-cache

B private, max-age=0

C public, max-age=3600

D no-store

💡 Hint

Check the 'Cache-Control Header Set' column at step 3 in the execution_table.

At which step does the client start serving the response from its cache?

A Step 4

B Step 5

C Step 2

D Step 6

💡 Hint

Look at the 'Effect on Client Cache' column to find when the client uses cached data.

If max-age was set to 0, how would the execution_table change at step 5?

A Client would send a new request at step 5

B Cache-Control header would be missing

C Client would serve from cache at step 5

D nginx would not add any header

💡 Hint

max-age=0 means no caching; check client cache behavior in variable_tracker.

Concept Snapshot

Cache-Control headers in nginx:
Use add_header directive inside location or server block.
Example: add_header Cache-Control "public, max-age=3600";
Controls how browsers cache responses.
max-age sets seconds to keep cached copy.
public means cacheable by any cache.

Full Transcript

This visual execution shows how nginx adds Cache-Control headers to HTTP responses. When a client requests a resource under /static/, nginx adds the header 'Cache-Control: public, max-age=3600'. This tells the client to cache the response for 3600 seconds. The client stores the response and serves it from cache for any requests within that time, avoiding new server requests. After 3600 seconds, the client considers the cache expired and requests the resource again from the server. nginx itself does not cache the response here; it only instructs the client how to cache. This flow helps improve performance by reducing repeated server requests for static content.

Practice

1. What is the purpose of the Cache-Control header in nginx?

easy

A. To set the server's IP address

B. To configure SSL certificates

C. To tell browsers how to cache files

D. To define the server's hostname

Solution

1. Step 1: Understand HTTP headers role

   HTTP headers communicate instructions between server and browser.

2. Step 2: Identify Cache-Control header function

   Cache-Control tells browsers how and when to cache content.

3. Final Answer:

   To tell browsers how to cache files -> Option C

4. Quick Check:

   Cache-Control = caching instructions [OK]

Hint: Cache-Control controls browser caching behavior [OK]

Common Mistakes:

• Confusing Cache-Control with server IP settings
• Thinking Cache-Control manages SSL
• Mixing Cache-Control with hostname configuration

2. Which is the correct nginx directive to add a Cache-Control header that caches content for 1 hour?

easy

A. add_header Cache-Control "max-age=3600";

B. cache_control add "max-age=3600";

C. set_header Cache-Control "max-age=3600";

D. header_add Cache-Control "max-age=3600";

Solution

1. Step 1: Recall nginx syntax for headers

   nginx uses add_header directive to add HTTP headers.

2. Step 2: Match correct syntax for Cache-Control

   The correct syntax is add_header Cache-Control "max-age=3600"; to set caching for 3600 seconds (1 hour).

3. Final Answer:

   add_header Cache-Control "max-age=3600"; -> Option A

4. Quick Check:

   add_header + Cache-Control + max-age=3600 = correct [OK]

Hint: Use add_header directive for Cache-Control in nginx [OK]

Common Mistakes:

• Using incorrect directive names like set_header
• Wrong order of words in directive
• Missing quotes around header value

3. Given this nginx config snippet:

location /images/ {
  add_header Cache-Control "public, max-age=86400";
}

What will the Cache-Control header instruct browsers for requests to /images/logo.png?

medium

A. Do not cache the image

B. Cache the image for 1 day and allow shared caches

C. Cache the image only privately for 1 hour

D. Cache the image forever without expiration

Solution

1. Step 1: Analyze Cache-Control directives

   "public" means cache is allowed by browsers and shared caches. "max-age=86400" means cache for 86400 seconds (1 day).

2. Step 2: Apply to /images/logo.png request

   Requests to /images/ get this header, so browsers and proxies cache the image for 1 day.

3. Final Answer:

   Cache the image for 1 day and allow shared caches -> Option B

4. Quick Check:

   public + max-age=86400 = 1 day shared cache [OK]

Hint: "public" + max-age seconds means shared cache allowed [OK]

Common Mistakes:

• Thinking "public" disables caching
• Confusing max-age seconds with hours
• Assuming private caching only

4. You added this line in nginx config:

add_header Cache-Control "max-age=3600";

But browsers still cache content longer than 1 hour. What is the likely problem?

medium

A. Cache-Control header is ignored by browsers

B. The max-age value is too low

C. You need to restart nginx for add_header to work

D. The add_header directive is inside a location block but response code is 304

Solution

1. Step 1: Understand add_header behavior with response codes

   By default, nginx does not add headers with add_header on 304 Not Modified responses.

2. Step 2: Identify why caching is longer

   If response is 304, Cache-Control header may be missing, causing browsers to use old cache rules.

3. Final Answer:

   The add_header directive is inside a location block but response code is 304 -> Option D

4. Quick Check:

   add_header skips 304 responses by default [OK]

Hint: add_header skips 304 responses unless configured [OK]

Common Mistakes:

• Assuming max-age value controls server cache
• Thinking browsers ignore Cache-Control
• Believing nginx restart fixes header issues

5. You want to configure nginx to prevent caching of API JSON responses but allow caching of static CSS files for 7 days. Which configuration is correct?

hard

A. location /api/ { add_header Cache-Control "no-store, no-cache, must-revalidate"; }
location /css/ { add_header Cache-Control "public, max-age=604800"; }

B. location /api/ { add_header Cache-Control "max-age=604800"; }
location /css/ { add_header Cache-Control "no-cache"; }

C. location /api/ { add_header Cache-Control "public, max-age=0"; }
location /css/ { add_header Cache-Control "private, max-age=604800"; }

D. location /api/ { add_header Cache-Control "max-age=0"; }
location /css/ { add_header Cache-Control "no-store"; }

Solution

1. Step 1: Prevent caching for API JSON responses

   Using "no-store, no-cache, must-revalidate" ensures browsers do not cache API responses.

2. Step 2: Allow caching for CSS files for 7 days

   "public, max-age=604800" allows shared caches and browsers to cache CSS for 604800 seconds (7 days).

3. Final Answer:

   location /api/ { add_header Cache-Control "no-store, no-cache, must-revalidate"; } location /css/ { add_header Cache-Control "public, max-age=604800"; } -> Option A

4. Quick Check:

   no-cache API + public 7-day CSS = correct config [OK]

Hint: Use no-cache for API, public max-age for static files [OK]

Common Mistakes:

• Mixing cache directives for API and static files
• Using private instead of public for CSS caching
• Setting max-age=0 for static files incorrectly