Expires: the older way to set a freshness lifetime

Expires names an absolute moment, which makes it fragile in a way max-age is not. The client compares that moment against its own clock, so a machine whose time is wrong caches for the wrong length, and a response sitting in a shared cache for an hour expires at the same instant for everyone regardless of when they received it.

That is why the relative directive won. max-age counts forwards from when the response was generated, so it survives a wrong client clock and behaves the same for a visitor arriving now as for one who arrived an hour ago. Where both headers are present, a cache that understands Cache-Control must ignore Expires entirely.

The value Expires: 0 appears in a great deal of old configuration. It is not a valid HTTP date, and the specification requires caches to read any invalid date, that one included, as a time already in the past. The effect is what the author intended, but writing an explicit past date or a Cache-Control directive states it more clearly.

It is still worth sending alongside Cache-Control when your traffic includes very old clients or corporate proxies. The two must agree: an Expires date a week away next to max-age=60 is not a compromise, it is a contradiction that different intermediaries will resolve differently.