Original comment by @costin:

Trying JDBC against a vanilla Elasticsearch, without X-Pack or SQL returns a 'weird' error:

Caused by: java.sql.SQLException: Server sent bad type [illegal_argument_exception]. Original type was [request [/_xpack/sql] contains unrecognized parameter: [mode]]. [java.lang.IllegalArgumentException: request [/_xpack/sql] contains unrecognized parameter: [mode]
	at org.elasticsearch.rest.BaseRestHandler.handleRequest(BaseRestHandler.java:92)
	at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:239)
	at org.elasticsearch.rest.RestController.tryAllHandlers(RestController.java:335)
	at org.elasticsearch.rest.RestController.dispatchRequest(RestController.java:173)

Notice that the error complains an obscure mode parameter when in fact the endpoint does not exist and hence the query is handled by the base handler which triggers the exception above.

The driver should be smarter than this and return an appropriate error message.
There are several approaches:

1. validate the connection

Before doing something on a connection do some kind of validation call (HTTP HEAD) or something along those lines. The issue however is that this adds up over time (we keep validating each connection so x2 calls) and it's also fairly light - we only know the endpoint is there, nothing beyond that.

2. recognize the exception pattern

Except the exception and handle it appropriately - this is similar to the security case, where we can look at the body and understand what went wrong without having to waste any extra calls. It's also something we can extend long term for things like not being able to open a connection, etc... (client issues).

My preference would be for 2.
Thoughts?