Expires directive in Nginx - Step-by-Step Execution

Process Flow - Expires directive

Client requests resource

↓

Nginx checks Expires directive

↓

Calculate expiration time

↓

Add Expires header to response

↓

Send response with Expires header

↓

Client caches resource until expiration

↓

After expiration, client requests resource again

This flow shows how nginx uses the Expires directive to tell browsers when a resource should be considered fresh or stale.

Execution Sample

Nginx

location /images/ {
    expires 30d;
}

This configuration tells nginx to add an Expires header to resources under /images/ that makes browsers cache them for 30 days.

Process Table

Step	Action	Expires Directive Value	Expires Header Sent	Effect on Client
1	Client requests /images/logo.png	30d	Expires: current_time + 30 days	Client caches resource for 30 days
2	Client requests /images/banner.jpg before 30 days	30d	Expires header still valid	Client uses cached resource, no new request sent
3	Client requests /images/banner.jpg after 30 days	30d	Expires header expired	Client sends new request to server
4	Server responds with new Expires header	30d	Expires: current_time + 30 days	Client caches updated resource again

💡 Client stops using cached resource after expiration time passes, triggering a new request

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4
Expires Header	None	current_time + 30 days	current_time + 30 days (still valid)	Expired	current_time + 30 days (new)
Client Cache State	Empty	Cached resource valid	Cached resource valid	Cache expired	Cached resource valid

Key Moments - 2 Insights

Why does the client not request the resource again before the expiration time?

Because the Expires header tells the client the resource is still fresh, so it uses the cached copy without asking the server again, as shown in execution_table row 2.

What happens when the expiration time passes?

The client considers the cached resource stale and sends a new request to the server, as shown in execution_table row 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the Expires header value sent at step 1?

A Expires: current_time + 30 days

B Expires: current_time + 1 day

C Expires: current_time + 1 hour

D No Expires header sent

💡 Hint

Check the 'Expires Header Sent' column in execution_table row 1

At which step does the client send a new request because the cached resource expired?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Effect on Client' column in execution_table row 3

If the expires directive was changed to '10d', how would the client's cache state change after step 2?

A Cache would never expire

B Cache would expire after 30 days

C Cache would expire after 10 days instead of 30

D Cache would expire immediately

💡 Hint

Refer to variable_tracker for 'Client Cache State' and how expiration time affects caching

Concept Snapshot

Expires directive in nginx sets how long browsers cache resources.
Syntax: expires <time>;
Example: expires 30d; caches for 30 days.
Nginx adds Expires header with future date.
Browsers use this to avoid re-requesting until expired.
Helps improve site speed by reducing server load.

Full Transcript

The Expires directive in nginx tells browsers how long to keep a resource cached. When a client requests a resource, nginx adds an Expires header with a date in the future based on the directive value. The client then caches the resource and uses it without asking the server again until the expiration date passes. After expiration, the client requests the resource again, and nginx sends a new Expires header to refresh the cache. This process helps reduce server load and speeds up page loading by avoiding unnecessary requests.