Read a retirement hint, not a guarantee
01A Sunset response field advertises when a resource is expected to become unresponsive; it does not guarantee availability on either side of that date.
3xx, 4xx, no response or continued availability are possible; Sunset alone does not select one.
Source for this drawing: RFC 8594 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- HTTP
- Hypertext Transfer Protocol, used for requests and responses on the web.
- Resource / URI
- A resource is the thing a URI identifies; a URI is an identifier such as a web address.
- Sunset
- A named response field giving a possible retirement time; it is not an acronym.
- Decommission versus deprecate
- Stopping availability differs from merely discouraging use of an API that still works.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Treat the timestamp as a hint and test actual availability by interacting.
- Sunset carries a single HTTP-date timestamp and SHOULD advertise a future time. A past timestamp is safest treated as meaning the present: the resource might become unavailable at any time.
- Clients SHOULD treat Sunset timestamps as hints, not guarantees. The date may change or be withdrawn, and an intermediary might have inserted it. A client that ignores the field can continue as usual, without advance warning.
- The field is appropriate for expected decommissioning, not merely saying that an otherwise operational API is no longer preferred. After the time, responses may be 3xx, 4xx or absent; neither a specific 410 nor automatic redirection is promised.
- HTTP-date generation uses IMF-fixdate under the referenced RFC 7231 §7.1.1.1. The example uses the valid Wednesday timestamp from RFC 8594 §9, rather than treating a date as a Unix integer or a duration.
Fictional response observed on 20 October 2026: Sunset: Wed, 11 Nov 2026 11:11:11 GMT. This copies the RFC §9 date as an example, not a required retirement interval. The final branches are possible later outcomes, not one mandatory sequence; the resource could remain available. The displayed 200 is explicitly the earlier response, not proof of later availability.
Read the RFC section ↗