3.2.0-rc1 doesn't handle API not found errors correctly

[matthewdarwin]

In all previous versions of nodeos, any 404 not-found errors are returned as JSON documents. In 3.2.0-rc1 a plain text error message is returned, but the content type is still application/json.

Either the content-type needs to be changed, or the content. I think the content should be changed to match previous version to not break backwards compatibility. Tools test URLs to understand if APIs are available or not. (eg account API).

3.2.0-rc1:

$ curl -v http://localhost:8888/
*   Trying 127.0.0.1:8888...
* Connected to localhost (127.0.0.1) port 8888 (#0)
> GET / HTTP/1.1
> Host: localhost:8888
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Content-Type: application/json
< Server: Boost.Beast/248
< Content-Length: 31
<
* Connection #0 to host localhost left intact
The resource '/' was not found.#                                                                                                                                                                               

Older:

$ curl -v http://localhost:8888/
*   Trying 127.0.0.1:8888...
* Connected to localhost (127.0.0.1) port 8888 (#0)
> GET / HTTP/1.1
> Host: localhost:8888
> User-Agent: curl/7.74.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 Not Found
< Connection: close
< Content-Length: 210
< Content-type: application/json
< Server: WebSocket++/0.7.0
<
* Closing connection 0
{"code":404,"message":"Not Found","error":{"code":0,"name":"exception","what":"unspecified","details":[{"message":"Unknown Endpoint","file":"http_plugin.cpp","line_number":597,"method":"handle_http_request"}]}}#

[kj4ezj]

From IM.

I'll add, when endpoints that normally return JSON return non-JSON (e.g. in an error case), it can make the client code much more complicated, or errors incredibly hard to diagnose.

For example, my favorite thing at my last job is when people would come to me for help with an error they didn't understand and I would see "< is not a valid character" or something like that. That pretty much meant an endpoint expected to return JSON returned an HTML page with a 400 or 500 error message. I only recognized it so quickly because I spent so many times taking hours to figure it out. The systems usually don't print or log the HTML response, so you still don't know what went wrong. Sometimes they do.

But it is very common for engineers to spend 1-2 hours trying to figure this out.

If an endpoint is expected to return JSON, it saves a lot of time and money if it just always returns JSON, even in error conditions. Tools like curl that work either way will display the error JSON.