Have you considered using AUTH_SWITCH_REQUEST for that purpose? That would allow redirect to happen after switch to TLS and client/server certificate validation.
One of the main use cases at the moment is to redirect clients to another server when this current server is being shut down.
For that we need to be able to send the redirect information in the middle of the session, not only when a connection is being established. Both session tracking and error message approach allow that.
Not strictly so - we don't *need* to send the redirect information in the middle of the session. The session can just be dropped, and when clients automatically reconnect they will get the error message (if old client software) or do an automatic redirect to the new server (if https://github.com/MariaDB/server/pull/2681 is merged). This is similar to how HTTP 301/302 redirects work, and pretty sweet as it allows to gracefully drain the old server and for clients to fall back on tried-and-tested semantics on what is done on connection interrupts. Consider this scenario: 1. Server A is getting 1 new connection per second, has 100 existing active connections, which of 10 are actually doing a query and 2 of them are long-running transactions. 2. Admin prepares server B to replicate server A data, and once replica lag is low runs on server A: SET GLOBAL SERVER_REDIRECT_TARGET=sever-b.example.com 3. Server A redirects all new connections, server B gets 1 new connection per second but does not yet serve traffic, clients re-try connections/queries 4. Server A drops 98 connections, 2 continue with long-running transaction 5. After defined delay, server A also drops the long-running transaction connections to avoid being stuck on them 6. All traffic is hitting server B, which catching up in replication, clients keep re-connecting 7. Server B has caught up, get's promoted to primary, and starts accepting connections 8. Server B serves at this point all traffic, and clients/applications continue to work without errors as long as the total switchover delay was shorter than the configured re-try delay of clients 9. Server A serves no queries, all clients connecting to it get redirected to server B - after some delay server A can be completely shut down 10. If any of the clients had an old version of the MariaDB connector, they will stop working but error logs will clearly show that a redirect happened. No extra proxy software is necessary nor pre-distributed configuration. This redirect can be done even in an emergency without prior preparations if server A for example is stalled on a deadlock or if server A was overloaded and a failover to a new server with better hardware is needed.