- From: RFC Errata System <rfc-editor@rfc-editor.org>
- Date: Fri, 13 Jun 2025 11:04:51 -0700 (PDT)
- To: bosko.stupar@gmail.com, fielding@gbiv.com, mnot@mnot.net, julian.reschke@greenbytes.de
- Cc: mbishop@evequefou.be, iesg@ietf.org, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
The following errata report has been rejected for RFC9110, "HTTP Semantics". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8459 -------------------------------------- Status: Rejected Type: Technical Reported by: Bosko Stupar <bosko.stupar@gmail.com> Date Reported: 2025-06-13 Rejected by: Mike Bishop (WIT AD) (IESG) Section: 15 Original Text ------------- The status code of a response is a three-digit integer code that describes the result of the request and the semantics of the response, including whether the request was successful and what content is enclosed (if any). All valid status codes are within the range of 100 to 599, inclusive. Corrected Text -------------- The status code of a response is a three-digit integer code that describes the result of the request and the semantics of the response, including whether the request was successful and what content is enclosed (if any). All valid status codes are within the range of 100 to 999, inclusive. Notes ----- In the initial RFC 7231 which was obsoleted by this one, we had simple definition of a status code which was used to build http servers, clients and libraries that are being used now "The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.". A lot of old systems are based on RFC 7231 and are using status codes that are in rage of 600 - 999. Those codes are mainly used to describe errors that aren't covered in previous status codes. For example we have payment system that can return e.g. "677 Invalid card number" and no body. Now we'd probably return "400 Bad request" with e.g. json body in which we have error message. This RFC should be backward compatible, and not to define breaking changes. If breaking changes are defined, it should be promoted more and talked about it between the community, give developers of old systems a time to align with new RFC, etc. Due to all of this, I'm suggesting that we omit all parts in this section that are limiting status codes to be only in range from 100 to 599, and update it accordingly so it support status codes from 100 to 999. --VERIFIER NOTES-- Section 6 of RFC 7231 also says "There are five values for the first digit" and lists 1xx through 5xx. Going further back, RFC 2616 contains identical language in Section 6.1.1; RFC 2068 contains identical language in its Section 6.1.1. This is not only not a recent change, it's not a change at all. This is the way HTTP has operated for decades, the reporter's noncompliant systems notwithstanding. -------------------------------------- RFC9110 (draft-ietf-httpbis-semantics-19) -------------------------------------- Title : HTTP Semantics Publication Date : June 2022 Author(s) : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed. Category : INTERNET STANDARD Source : HTTP Stream : IETF Verifying Party : IESG
Received on Friday, 13 June 2025 18:04:55 UTC