Bug #90331 Server does not raise error on unrecognized collation id
Submitted: 6 Apr 2018 23:28 Modified: 6 Sep 2018 18:18
Reporter: Manuel Ung Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: C API (client library) Severity:S3 (Non-critical)
Version:5.6 8.0 OS:Any
Assigned to: CPU Architecture:Any

[6 Apr 2018 23:28] Manuel Ung
If a newer client (eg. 8.0) connects to an older server, it may request a collation id that is not available on the older server in the handshake response.

This is bad because the server silently falls back to its default character set, while the client is under the impression that data is coming in its requested character set. This could cause data corruption.

How to repeat:
Connect to 5.6 server with 8.0 mysql cli. Observe that it succeeds, but character_set_server on the connection is not utf8mb4, which is expected by the client.

Suggested fix:
Server should return an error when collation id is not recognized upon connection.
[7 Apr 2018 10:08] Umesh Shastry
Hello Manuel Ung,

Thank you for the report and feedback.

[20 Apr 2018 2:58] Manuel Ung
I also found out that this causes functions like mysql_real_escape_string to behave differently, because client will escape assuming utf8mb4 but server is still on latin1.
[6 Sep 2018 18:18] Paul Dubois
Posted by developer:
This was assessed not to be a bug, but the behavior was not described in the docs. It's now explained here:
(See the error-handling subsection.)

A client that needs to check whether the server honored the requested character set can check the character set using:

SELECT @@character_set_client;

and if necessary, can select the requested character set using SET NAMES.