Modified condition from gt to gte for distinguishing OK Packet from EOF Packet

[daniyaalk]

Incorrect length condition in documentation for OK_Packet

In the documentation for OK_Packet in sql/protocol_classic.cc:721, it is mentioned that the condition header=0 and length of packet > 7 may be used to distinguish a packet as an OK packet. However, there may be scenarios when an OK Packet length is of excatly 7 bytes.

One such scenario is the OK Packet received after successful authentication using Protocol::AuthSwitchResponse:, which is as folows:

0000   07 00 00 04 00 00 00 02 00 00 00

This was observed on:

Server Version: 8.0.32
Server Capabilities: 0xffff

Client Version: Ver 8.0.40-0ubuntu0.24.10.1 for Linux on x86_64 ((Ubuntu))
Client Capabilities Bitmask: 0xa65
Extended Client Capabilities Bitmask: 0x19ff

Command used for login:

mysql -uroot -pasd -h127.0.0.1 -P3307 --ssl-mode=DISABLED

Annotated packet dump follows:

Server: Greeting

0000   4a 00 00 00 0a 38 2e 30 2e 33 32 00 96 00 00 00   J....8.0.32.....
0010   4f 73 20 51 29 06 7e 01 00 ff ff ff 02 00 ff df   Os Q).~.........
0020   15 00 00 00 00 00 00 00 00 00 00 1b 55 5c 12 30   ............U\.0
0030   05 03 0c 41 71 20 18 00 63 61 63 68 69 6e 67 5f   ...Aq ..caching_
0040   73 68 61 32 5f 70 61 73 73 77 6f 72 64 00         sha2_password.

Client: Login Request

0000   d4 00 00 01 85 a6 ff 19 00 00 00 01 ff 00 00 00   ................
0010   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0020   00 00 00 00 72 6f 6f 74 00 20 b8 f2 a6 a7 46 af   ....root. ....F.
0030   02 58 0e f3 a4 c8 90 fe 9a fd 99 56 fb d5 54 a8   .X.........V..T.
0040   f8 1c 44 44 b9 5a 3b c1 65 4d 63 61 63 68 69 6e   ..DD.Z;.eMcachin
0050   67 5f 73 68 61 32 5f 70 61 73 73 77 6f 72 64 00   g_sha2_password.
0060   77 04 5f 70 69 64 05 37 30 37 39 30 09 5f 70 6c   w._pid.70790._pl
0070   61 74 66 6f 72 6d 06 78 38 36 5f 36 34 03 5f 6f   atform.x86_64._o
0080   73 05 4c 69 6e 75 78 0c 5f 63 6c 69 65 6e 74 5f   s.Linux._client_
0090   6e 61 6d 65 08 6c 69 62 6d 79 73 71 6c 07 6f 73   name.libmysql.os
00a0   5f 75 73 65 72 08 64 61 6e 69 79 61 61 6c 0f 5f   _user.daniyaal._
00b0   63 6c 69 65 6e 74 5f 76 65 72 73 69 6f 6e 06 38   client_version.8
00c0   2e 30 2e 34 30 0c 70 72 6f 67 72 61 6d 5f 6e 61   .0.40.program_na
00d0   6d 65 05 6d 79 73 71 6c                           me.mysql

Server: Auth Switch Request

0000   2c 00 00 02 fe 6d 79 73 71 6c 5f 6e 61 74 69 76   ,....mysql_nativ
0010   65 5f 70 61 73 73 77 6f 72 64 00 4f 73 20 51 29   e_password.Os Q)
0020   06 7e 01 1b 55 5c 12 30 05 03 0c 41 71 20 18 00   .~..U\.0...Aq ..

Client: Auth Switch Response

0000   14 00 00 03 75 49 48 03 24 79 da d2 8e e0 b8 00   ....uIH.$y......
0010   06 75 20 73 60 40 b5 22                           .u s`@."

Server: OK

0000   07 00 00 04 00 00 00 02 00 00 00                  ...........

[mysql-oca-bot]

Hi, thank you for your contribution. Please confirm this code is submitted under the terms of the OCA (Oracle's Contribution Agreement) you have previously signed by cutting and pasting the following text as a comment:
"I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it."
Thanks

[daniyaalk]

I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

[daniyaalk]

The example in the doxygen docs itself also contains an OK Packet with length of exactly 7 bytes

mysql-server/sql/protocol_classic.cc

Lines 733 to 743 in 6b6d3ed

	Example
	=======
	OK with ::CLIENT_PROTOCOL_41. 0 affected rows, last-insert-id was 0,
	AUTOCOMMIT enabled, 0 warnings. No further info.
	~~~~~~~~~~~~~~~~~~~~~
	07 00 00 02 00 00 00 02 00 00 00
	~~~~~~~~~~~~~~~~~~~~~

[mysql-oca-bot]

Hi, thank you for your contribution. Your code has been assigned to an internal queue. Please follow
bug http://bugs.mysql.com/bug.php?id=117374 for updates.
Thanks