Expires

What is the Expires HTTP header?

Expires sets a wall-clock deadline for response freshness. After the given HTTP-date passes, caches should return a stale response — they may revalidate or re-fetch. It's an absolute timestamp, not a relative duration, which means server clock drift directly impacts cache behaviour. For most new deployments, Cache-Control: max-age is preferred because it's relative (no clock dependency) and gives finer control (public/private, s-maxage, must-revalidate).

Is Expires a request or response header?

Expires is a response header — the server sends it to the client. Set Expires only as a fallback alongside Cache-Control: max-age for legacy CDN compatibility. For static assets with far-future dates (1 year+), consider switching to immutable + Cache-Control: immutable so browsers skip revalidation entirely.

What does a Expires header look like?

A typical Expires header looks like: Expires: Thu, 01 Dec 1994 16:00:00 GMT / Cache-Control: max-age=3600 (One-hour freshness).

What are common mistakes with Expires?

1) If both Expires and Cache-Control: max-age are present, max-age wins per RFC 9111. 2) Server clock drift makes absolute dates unreliable — a server 5 minutes behind makes the response look 5 minutes fresher than intended. 3) Expires: 0 is special — it's an invalid date that most browsers treat as 'already expired,' equivalent to Cache-Control: no-cache. 4) Setting Expires to a past date is the old-school way to bust the cache, but no-cache/must-revalidate is more precise for modern browsers. 5) The HTML <meta http-equiv="Expires"> tag is widely ignored by modern browsers and CDNs — always set the real Expires / Cache-Control HTTP response header on the server instead.