· 6 years ago · Apr 01, 2020, 11:30 AM
1
2
3
4
5
6
7Internet Engineering Task Force (IETF) B. Dover
8Request for Comments: 8969
9Category: Standards Track April 2020
10ISSN: 2071-1769
11
12
13 An HTTP Status Code to Indicate Request Noncomformity While Still
14 Making Best-Effort Response
15
16Abstract
17
18 This document specifies a Hypertext Transfer Protocol (HTTP) status
19 code for use when resource was accessed in a nonconforming manner
20 but the request will be handled anyway.
21
22Status of This Memo
23
24 This is an Internet Standards Track document.
25
26 This document is a product of the Internet Engineering Task Force
27 (IETF). It represents the consensus of the IETF community. It has
28 received public review and has been approved for publication by the
29 Internet Engineering Steering Group (IESG). Further information on
30 Internet Standards is available in Section 2 of RFC 5741.
31
32 Information about the current status of this document, any errata,
33 and how to provide feedback on it may be obtained at
34 http://www.rfc-editor.org/info/rfc8969.
35
36Copyright Notice
37
38 Copyright (c) 2020 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
40
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
50
51
52
53
54
55
56
57
58
59Dover Standards Track [Page 1]
60
61RFC 8969 HTTP-status-397 April 2020
62
63
64Table of Contents
65
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
67 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2
68 3. 397 Tolerating . . . . . . . . . . . . . . . . . . . . . . . 2
69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
70 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5
72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
73
741. Introduction
75
76 This document specifies a Hypertext Transfer Protocol (HTTP) status
77 code for use when a server operator has received a request that
78 violates standards for making such a request, but which the server
79 will respond to under best-faith intepretation of client intent.
80
81 This status code can be used to alert clients of their standards
82 breakage and the potential that future requests of this type might
83 not be handled as desired by this or other internet servers in the
84 future.
85
86 [RFC761] Section 2.10 discusses the Robustness Principle under which
87 one should be liberal in what one accepts; in keeping with that
88 principle, servers shdould make a best effot to handle non-conforming
89 requests; this status code additionally provides a way to communicate
90 to the client that it is doing so, and how to avoid potential breakage
91 in the future.
92
932. Requirements
94
95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
97 document are to be interpreted as described in [RFC2119].
98
993. 397 Tolerating
100
101 This status code indicates that the server has found a standards
102 violation in the client request, but will respond in good faith
103 anyway to the most likely intended conforming request.
104
105 Responses using this status code SHOULD include an explanation, in
106 the response body, of the details of the standards breakage; what the
107 client sent, versus what the client should have sent. For example:
108
109
110
111
112
113
114
115Dover Standards Track [Page 2]
116
117RFC 8969 HTTP-status-397 April 2020
118
119
120 HTTP/1.1 397 Tolerating
121 Link: <https://www.example.org/news>;
122 Content-Type: text/html
123 Request-Nonconformity: This request used the HTTP header "Referrer",
124 which is most likely intended to be the standard HTTP header
125 "Referer"; request will be handled on this assumption, and the
126 client is advised to update code to "Referer" for future requests.
127 Request-Nonconformant-Part: Referrer: http://search.example.com
128 Request-Interpreted-As: Referer: http://search.example.com
129 Tolerated-Until: Fri, 30 Apr 2020 06:05:18 GMT
130
131
132 The use of the 397 status code does not imply an obligation to
133 tolerate the nonconformity in the future. Servers MAY specify the
134 tolerance's ending time with the Tolerated-Until response header.
135
136 Clients SHOULD monitor their server logs for computer-initiated API
137 requests in order to detect 397 responses and appropriate update
138 their software to be in order to conform with relevant RFCs.
139
140 A 397 response MUST be followed by another HTTP response, similar
141 to other 300-series HTTP status codes, where such response makes
142 the best guess at what the client intended; in the example above, that
143 would be the response the client would have received from "Referer".
144
1454. IANA Considerations
146
147 The HTTP Status Codes Registry has been updated with the following
148 entry:
149
150 o Code: 397
151
152 o Description: Tolerating
153
154 o Specification: RFC 8969
155
156 The Standard Header Registry has been updated with the following
157 entries:
158
1594.1. Request-Nonconformity
160
161 o Header Name: Request-Nonconformity
162
163 o Description: Human-readable explanation about what is wrong
164 with the request.
165
166 o Reference: RFC 8969
167
168
169
170
171Dover Standards Track [Page 3]
172
173RFC 8969 HTTP-status-397 April 2020
174
175
1764.2. Request-Nonconformant-Part
177
178 o Header Name: Request-Nonconformant-Part
179
180 o Description: Repeats back the part of the request that is non-
181 conforming.
182
183 o Reference: RFC 8969
184
1854.3. Request-Interpreted-As
186
187 o Header Name: Request-Interpreted-As
188
189 o Description: The corrected version of the non-conformant part
190 that the server will interpret the request as.
191
192 o Reference: RFC 8969
193
1944.4. Tolerated-Until
195
196 o Header Name: Request-Interpreted-As
197
198 o Description: The date and time, formatted per [RFC7231], after
199 which the server will stop thusly correcting this request error.
200
201 o Reference: RFC 8969
202
2036. References
204
2056.1. Normative References
206
207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
208 Requirement Levels", BCP 14, RFC 2119,
209 DOI 10.17487/RFC2119, March 1997,
210 <http://www.rfc-editor.org/info/rfc2119>.
211
212 [RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
213 Transfer Protocol (HTTP/1.1): Semantics and Content",
214 RFC 7231, DOI 10.17487/RFC7231, June 2014,
215 <https://www.rfc-editor.org/info/rfc7231>.
216
2176.2. Informative References
218
219 [RFC761] Postel, J., "DoD standard Transmission Control Protocol",
220 RFC 761, DOI 10.17487/RFC0761, January 1980,
221 <https://www.rfc-editor.org/info/rfc761>.
222
223
224
225
226
227Dover Standards Track [Page 4]
228
229RFC 8969 HTTP-status-397 April 2020
230
231
232
233 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
234 Communication Layers", STD 3, RFC 1122, DOI 10.17487/
235 RFC1122, October 1989,
236 <https://www.rfc-editor.org/info/rfc1122>.
237
238Acknowledgements
239
240 Thanks to the field of numerology for providing 97 as the number
241 for tolerance.
242
243Author's Address
244
245 Ben Dover
246
247 Email: benjamin.jeremiah.dover@gmail.com
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269Dover Standards Track [Page 5]
270