1. HTTP (Hypertext Transfer Protocol)

  1. HTTP Headers

  1. Expires
    1. Reading responses
    2. Writing responses
    3. Overview table
    4. Syntax
      1. Example
    5. History

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

  1. 1999-06: RFC 2616 §14.21. Expires
  2. 2014-06: RFC 7234 §5.3. Expires
  3. 2022-06: RFC 9111 §5.3. Expires