Expires
The "Expires" response header specifies how long a response may be cached. After the expiration date, the response may be re-used after it is freshened with revalidation from the origin server. The max-age
and s-maxage
directives in Cache-Control are preferred.
Reading responses
The Expires
header does not affect how a client handles the response to a request, except for storing the response for future re-use; and if the response is stored, it is used to determine for how long it may be re-used without revalidating the request with the origin.
If the response Cache-Control specifies a max-age
directive, then ignore this header, since it takes precedence. If Cache-Control specifies an s-maxage
directive, then shared caches must ignore this header, since it takes precedence.
The syntax follows the HTTP-date production, the same as in the Date header. Interpret an invalid value as already expired.
Writing responses
Servers may only generate an Expires header if they know the date is accurate. Servers that do not have a reliable clock may only send Expires if it is a date known to be in the past, or if the date to be used is from an outside source that does have a reliable clock. For specifying a relative offset, use Cache-Control with max-age.
Overview table
- Name
- Expires
- Description
- How long a response may be cached without revalidation.
- Direction
- Response
- Specification
- RFC 9111: HTTP Caching §5.3. Expires
Syntax
Expires = HTTP-date
Example
Expires: Thu, 01 Dec 1994 16:00:00 GMT
History
- 1999-06: RFC 2616 §14.21. Expires
- 2014-06: RFC 7234 §5.3. Expires
- 2022-06: RFC 9111 §5.3. Expires