- From: RFC Errata System <rfc-editor@rfc-editor.org>
- Date: Fri, 13 Jun 2025 03:56:16 -0700 (PDT)
- To: fielding@gbiv.com, mnot@mnot.net, julian.reschke@greenbytes.de, httpbis-ads@ietf.org, mnot@mnot.net, tpauly@apple.com
- Cc: bosko.stupar@gmail.com, ietf-http-wg@w3.org, rfc-editor@rfc-editor.org
The following errata report has been submitted for RFC9110, "HTTP Semantics". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8459 -------------------------------------- Type: Technical Reported by: Bosko Stupar <bosko.stupar@gmail.com> 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. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- 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 10:56:20 UTC