Re: [Technical Errata Reported] RFC9110 (8459)

Hello,

On Fri, Jun 13, 2025 at 03:56:16AM -0700, RFC Errata System wrote:
> 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.".

The same spec you quoted further says:

  "However, a client MUST understand the class of any status code,
   as indicated by the first digit,"

then

  "There are five values for the first digit"

then goes on with 1xx to 5xx.

> 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.

Well, based on the text above (section 6), I find it particularly
difficult to imagine how 600-999 could be permitted at all given
that they don't fit into the five values for the first digit!

> For example we have payment system that can return e.g. "677 Invalid card
> number" and no body. 

Then no client is supposed to be able to process this, based on the text
above.

> Now we'd probably return "400 Bad request" with e.g.
> json body in which we have error message.

Or you can also define any other 4xx that suits you, and/or use a specific
header field to pass the information.

> 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.

Fortunately on this point the spec remains compatible, what you're reporting
seems to stem from a misunderstanding or a partial reading, I don't know,
but the spec is extremely clear on this point.

Also I've heard that some products use 6xx-9xx for internal use (i.e. never
goes to the wire), your request would cause serious trouble to them!

IMHO here it's a REJECT.

Regards,
Willy

Received on Friday, 13 June 2025 12:36:36 UTC