You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 7, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: draft-ietf-httpapi-deprecation-header.md
+18-28Lines changed: 18 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -131,6 +131,14 @@ The following example uses the same link header field, but also announces a depr
131
131
132
132
Given that the deprecation date is in the past, the linked information resource may have been updated to include information about the deprecation, allowing consumers to discover information about the deprecation and how to best manage it.
133
133
134
+
### Security Considerations
135
+
136
+
The Deprecation header field SHOULD be treated as a hint, meaning that the resource is indicating (and not guaranteeing with certainty) that it will be or is deprecated. Applications consuming the resource SHOULD check the resource documentation to verify authenticity and accuracy. Resource documentation SHOULD provide additional information about the deprecation, potentially including recommendation(s) for replacement.
137
+
138
+
In cases where the Deprecation header field value is a date in the future, it can lead to information that otherwise might not be available. Therefore, applications consuming the resource SHOULD verify the resource documentation and if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to recommended resource.
139
+
140
+
In cases where a `Link` header field is used to provide documentation, one should assume that the content of the `Link` header field may not be secure, private or integrity-guaranteed, and due caution should be exercised when using it. Applications consuming the resource SHOULD check the referred resource documentation to verify authenticity and accuracy.
141
+
134
142
135
143
# Sunset
136
144
@@ -151,7 +159,7 @@ The act of deprecation does not change any behavior of the resource. Deprecated
151
159
152
160
## The Deprecation HTTP Response Header Field
153
161
154
-
The `Deprecation` response header field should be added to the permanent registry of message header fields (see {{!RFC3864}}).
162
+
The `Deprecation` response header field should be added to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry ({{Section 16.3.1 of HTTP}})
155
163
156
164
Header Field Name: Deprecation
157
165
@@ -188,6 +196,15 @@ The `deprecation` link relation type should be added to the permanent registry o
188
196
Section 3 "The Deprecation Link Relation Type"
189
197
190
198
199
+
# Examples
200
+
201
+
The following example does not show complete HTTP interaction. It only shows those HTTP header fields in a response that are relevant for resource deprecation.
The Deprecation header field SHOULD be treated as a hint, meaning that the resource is indicating (and not guaranteeing with certainty) that it will be or is deprecated. Applications consuming the resource SHOULD check the resource documentation to verify authenticity and accuracy. Resource documentation SHOULD provide additional information about the deprecation, potentially including recommendation(s) for replacement.
275
-
276
-
In cases where the Deprecation header field value is a date in the future, it can lead to information that otherwise might not be available. Therefore, applications consuming the resource SHOULD verify the resource documentation and if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to recommended resource.
277
-
278
-
In cases where a `Link` header field is used to provide documentation, one should assume that the content of the `Link` header field may not be secure, private or integrity-guaranteed, and due caution should be exercised when using it. Applications consuming the resource SHOULD check the referred resource documentation to verify authenticity and accuracy.
279
-
280
-
281
-
# Examples
282
-
283
-
The following examples do not show complete HTTP interactions. They only show those HTTP header fields in a response that are relevant for resource deprecation.
284
-
285
-
The first example shows a deprecation header field with date information:
286
-
287
-
Deprecation: @1688169599
288
-
289
-
The second example shows a deprecation header field with a link for the resource's deprecation policy. In addition, it shows the sunset date for the deprecated resource:
0 commit comments