Re: http: Diagnostic instead of reason codes Q

Thanks, Lucas!

Of course, a minute after i wrote my original mail, i did stumble across
rfc9457, even though i spent hours searching in before *sigh*. It's almost as if
there's a need to first write some clueless email before searches will make me find stuff.
(it's a conspiracy ;-).

But  9205 is a good additional read for me. Hadn't stumbled across that one.

Now of course, when going to promote 9457, it starts to become real work to
build out good error diagnostics. Cynical as i am, if i would be cloning
what i am seeing in other parts of the industry, the responses would be something like:

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json
Content-Language: en

{
 "type": "urn:ietf:params:<protocol>:error:CrypticVendorError",
 "detail": "WorstSoftwareEver, v0.01xy, code: 0x47110815",
}

Which unfortunately is still better than not having an error code at all, but it's
the "call up vendor support, they will let you go through 1 month of hoops for someone
in L3 support to grep for 0x47110815 in the source code of v0.01xy and then
try to analyze what that error means". 

But of course, any better definition of error codes is real standards work ;-))
Only few protocols from IETF seem to ahve done this. Luckily there are some, ACME looks nice
for example.

Cheers
    Toerless

Received on Wednesday, 6 September 2023 17:28:26 UTC