silasx

RFC 8969: HTTP 397 Tolerating

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