The Deprecation HTTP Response Header Field

Deprecation does not change any behavior of the resource. It is purely informational, signaling lifecycle state to client application developers without altering the resource's function or semantics.

http

Deprecation-related information is only a hint; it cannot be depended on. Client applications SHOULD always be implemented in ways that allow them to function without deprecation-related information, making increased scope hints safe to use even if partially invisible to consumers.

http

For historical reasons, the Sunset HTTP header field uses a different date format from the Deprecation header field. Deprecation uses the RFC 9651 structured date (Unix timestamp prefixed with `@`), while Sunset uses HTTP-date format.

http

The Deprecation header field applies only to the specific resource identified by the response (per Section 6.4.2 of RFC 9110). Servers may define an increased scope (e.g., all API resources), but consumers unaware of that scope will interpret the header as applying to the single resource only.

http

If the Sunset timestamp is earlier than the Deprecation timestamp (e.g., due to misconfiguration), the client application developer SHOULD consult the resource developer to get clarification.

http

The deprecation documentation MAY provide a migration guide and timeline for transitioning from the deprecated resource to a replacement, if applicable.

http

The Deprecation header field value MUST be a Date structured field. It conveys either a past deprecation date or a future planned deprecation date for the resource identified by the response.

http

The timestamp given in the Sunset HTTP header field MUST NOT be earlier than the one given in the Deprecation header field.

http

When the Deprecation header field value is a future date, client application developers SHOULD, if possible, consult the resource developer to discuss potential impact and plan transition to a recommended replacement resource.

http

The Deprecation HTTP response header field allows a server to signal to a client that a resource will be or has been deprecated. It conveys the deprecation date, which may be in the future or in the past.

http

The deprecation link relation type allows a server to link to human- or machine-readable documentation about the deprecation of the resource context. It can be sent before or after the actual deprecation date using a Link header field with `rel="deprecation"`.

http

The Sunset HTTP header field (RFC 8594) MAY be used alongside the Deprecation header field to indicate when the deprecated resource is expected to become unresponsive.

http

The Deprecation HTTP response header field has been registered in the IANA 'Hypertext Transfer Protocol (HTTP) Field Name Registry' with status 'permanent', structured type 'Item', referencing RFC 9745 Section 2.

http, registry

The 'deprecation' link relation type has been registered in the IANA 'Link Relation Types' registry, described as referring to documentation about the deprecation of the link's context, referencing RFC 9745 Section 3.

http, registry

Client application developers SHOULD always check the referred resource's documentation to verify authenticity and accuracy of deprecation information. When a Link header field provides documentation without HTTPS, its content may not be secure, private, or integrity-guaranteed.

http, security

The Deprecation header field is a hint only; the resource does not guarantee deprecation with certainty. Deprecated resources function as before, though non-functional aspects (efficiency, response times) may be affected.

http, security

When the Deprecation header field value is in the past, client application developers MUST no longer assume that the resource behavior will remain the same as before the deprecation date.

http, security

The Deprecation header field is an Item Structured Header Field; its value MUST be a Date as per Section 3.3.7 of RFC 9651 (Structured Field Values for HTTP). Example: `Deprecation: @1688169599`.

http