Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.11.7
-
None
Description
If the server returns a packet with an error number in the range between 2000 and 2999, the client library reports it as a malformed packet. This is technically a breaking change as it's not documented anywhere in the protocol or in the error code listings that the range 2000 to 2999 is reserved for client errors and they must be treated as malformed packets.
This breaks a module in MaxScale that (mistakenly) used the error code 2003 for an error it generated. If this range of error numbers is reserved for clients, it should be documented.
The commit that causes this is 4419abe71aef1d0b6ca0fab8fc67f02845b1e081. While this is merely a client-side change, it should either be reverted to retain the old documented behavior or it should be documented that the range 2000 to 2999 is reserved for client-side errors and any error packet from that range must be considered a malformed packet. I'd prefer the latter as it requires no changes to the server and/or client code and merely a fix in MaxScale.
Here is a post-authentication network capture that in 10.6 is reported as a "normal" error but in 10.11 is reported as a malformed packet:
T 192.168.122.1:36730 -> 192.168.122.131:4006 [AP] #105
|
1f 00 00 00 03 49 4e 53 45 52 54 20 49 4e 54 4f .....INSERT INTO
|
20 74 65 73 74 2e 74 32 20 56 41 4c 55 45 53 20 test.t2 VALUES
|
28 31 29 (1)
|
#
|
T 192.168.122.131:4006 -> 192.168.122.1:36730 [AP] #106
|
1e 00 00 01 ff d3 07 23 48 59 30 30 30 49 6e 76 .......#HY000Inv
|
61 6c 69 64 20 69 6e 73 65 72 74 20 74 61 72 67 alid insert targ
|
65 74 et
|
#
|
If nothing else, the error message is misleading since the packet itself is well-formed and it's only the error that is unknown.
Attachments
Issue Links
- relates to
-
MXS-5000 insertstream uses an error code from the reserved client range
- Closed