Expires
Description
The Expires response header indicates the date and time after which the response is considered stale. When a response's expiration time is reached, clients must validate their cached copy with the server before using it again. This header helps control caching behavior by explicitly defining how long a response remains fresh.
The Expires header was the primary mechanism for cache control in HTTP/1.0, but in HTTP/1.1, it's generally superseded by the more flexible Cache-Control header with the max-age directive. However, Expires is still widely used, often alongside Cache-Control, for maximum compatibility with different clients and caching systems.
It's worth noting that if both Cache-Control: max-age and Expires are present, the Cache-Control header takes precedence according to the HTTP specification.
Syntax
The syntax of the Expires header follows this structure:
<http-date>: A date and time in the HTTP date format (same format as theDateheader).
The date must be in the format defined by RFC 7231:
Example Syntax
This example indicates that the response will be considered stale after 11:00:00 GMT on June 4, 2025.
Examples
Basic Example
A response that expires in one day:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 11:00:00 GMT
Content-Type: image/jpeg
Content-Length: 12345
Expires: Tue, 03 Jun 2025 11:00:00 GMT
[... JPEG data ...]
In this example, the response will be considered fresh until 11:00:00 GMT on June 3, 2025, exactly 24 hours after it was generated.
Combined with Cache-Control Example
A response using both Expires and Cache-Control:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 11:15:30 GMT
Content-Type: text/css
Content-Length: 2345
Cache-Control: public, max-age=86400
Expires: Tue, 03 Jun 2025 11:15:30 GMT
body {
font-family: Arial, sans-serif;
color: #333;
}
/* ... more CSS ... */
In this example, both headers indicate the same expiration time (24 hours), providing compatibility with both HTTP/1.0 and HTTP/1.1 clients.
Immediate Expiration Example
A response that should not be cached:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 11:30:45 GMT
Content-Type: application/json
Content-Length: 67
Expires: Mon, 02 Jun 2025 11:30:45 GMT
{
"timestamp": 1717322645,
"random_value": 42
}
In this example, the Expires header is set to the same time as the Date header, indicating that the response is already expired when it is received, effectively preventing caching.
Far Future Expiration Example
A response that can be cached for a very long time:
HTTP/1.1 200 OK
Date: Mon, 02 Jun 2025 11:45:15 GMT
Content-Type: application/javascript
Content-Length: 34567
Expires: Mon, 02 Jun 2035 11:45:15 GMT
// JavaScript library with a very long cache time
function library() {
// ... code ...
}
In this example, the response is set to expire 10 years in the future, indicating that it can be cached for a very long time. This approach is often used for static resources that rarely change, like library files with versioned URLs.
Summary
The Expires response header provides a simple and direct way to control caching behavior by specifying an absolute time after which a response should be considered stale. While largely superseded by the more flexible Cache-Control header in modern applications, Expires remains valuable for compatibility with older clients and caching systems. When implementing caching strategies, it's common to include both Expires and Cache-Control headers for maximum compatibility, keeping in mind that Cache-Control will take precedence in HTTP/1.1 compliant clients.