RPC call returns HTTP 500 in case of data error

[denis-at-chainstack]

Describe the bug
When the request body contains invalid data (method name for example), for some reason Filecoin node return HTTP 500 code together with JSON containing all info about the error, while many other protocols return HTTP 200 in this case (with similar error JSON).
Normally HTTP 500 means server-error, supposing the client will retry the same request later. So it doesn't look like a proper code for this case.

To Reproduce

Steps to reproduce:

1. Run
   curl --location --request POST 'https://hyperspace.filfox.info/rpc/v0'
   --header 'Content-Type: application/json'
   --data-raw '{
   "jsonrpc": "2.0",
   "id": 1,
   "method": "Filecoin.WalletBalance",
   "params": []
   }
   '
2. Check the HTTP status code in response

Fact result:
The HTTP code is 500

Expected behavior:
HTTP code should be 200

Version (run lotus --version):
Filecoin.NetVersion returns 19
Filecoin.EthProtocolVersion returns 0x13
sorry, don't have access to the client itself

Artefacts

The response body for the request from the example:
{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"wrong param count (method 'Filecoin.WalletBalance'): 0 != 1"}}

[raulk]

It looks like the very early JSON-RPC specs mandated HTTP 500 for errors: https://www.jsonrpc.org/historical/json-rpc-over-http.html#id19. However, this was dropped as JSON-RPC 1.0 was standardised, and it continues to not be specified in JSON-RPC 2.0. I found this discussion thread: https://groups.google.com/g/json-rpc/c/2L_4zYIafGw/m/Oa_tEt-aAgAJ.

It seems like the common practice is to use HTTP 200 when no errors occured at the HTTP layer (e.g. authentication, parse errors, internal errors).

@jennijuju @arajasek — this would be a breaking change over the v1 API of Lotus. Could you please evaluate the impact on your Lotus clients?