Return a reason for 403 error on AuthRPC endpoint

[jakubgs]

System information

Geth version: 1.10.25
OS & Version: Linux
Commit hash : 69568c5

Expected behaviour

It would be beneficial for the sake of CL/EL node communication setup to indicate what's the actual reason for 403 HTTP error returned from an RPC or AuthRPC endpoint. My understanding is that there are at least two ways one can receive it from AuthRPC:

1. Wrong hostname - the host header - used for request not matching --http.vhosts/--authrpc.vhosts flag value.
2. Wrong JWT secret used for accessing the AuthRPC endpoint.

In the plain RPC case the first case is the only one possible as far as I know.

It would be great if Geth indicated which issue it is with either a payload or a different HTTP code.
For example 400 Bad Request for wrong host header value. Or a JSON payload with an actual error message.

Actual behaviour

Currently both errors cause a 403 error, for example:

 > curl -sSfv http://geth.example.org:8545
*   Trying 10.11.12.13:8546...
* Connected to geth.example.org (10.11.12.13) port 8546 (#0)
> GET / HTTP/1.1
> Host: geth.example.org:8545
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Sat, 17 Sep 2022 07:00:04 GMT
< Content-Length: 23
* The requested URL returned error: 403
* Closing connection 0
curl: (22) The requested URL returned error: 403

 > curl -sSfv http://localhost:8545                  
*   Trying 127.0.0.1:8545...
* Connected to localhost (127.0.0.1) port 8545 (#0)
> GET / HTTP/1.1
> Host: localhost:8546
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sat, 17 Sep 2022 07:00:07 GMT
< Content-Length: 0
< 
* Connection #0 to host localhost left intact

This can easily cause confusion since the obvious thing to blame is a wrong JWT token, but in reality it can be either or both.

Steps to reproduce the behaviour

1. Configure Geth with RPC and AuthRPC.
2. Make request with wrong vhost value in host header.
3. See the 403 response without payload.

[holiman]

Definitely, I support this

[fjl]

I have checked this and here is the current behavior.

The geth HTTP server returns status code 403 Forbidden with body "invalid host specified" when the host does not match vhosts. For errors related to JWT, we return status 401 Unauthorized with a response body stating the reason.

So the different cases can already be reasonably distinguished.

[jakubgs]

I see what's happening. It's my use of -f/--fail flag with curl that obscured this. If --fail-with-body is used I can see the error.

Thanks for checking and clarifying @fjl. This means we can give a clear indication as to the reason for RPC failure on BN side.