MySQL :: MySQL Internals Manual :: 15.2 Connection Phase

MySQL Internals Manual :: 15 MySQL Client/Server Protocol :: 15.2 Connection Phase

Section Navigation [Toggle]

15.2. Connection Phase

15.2.1. Initial Handshake
15.2.2. Auth Phase Fast Path
15.2.3. Authentication Method Mismatch
15.2.4. Authentication after COM_CHANGE_USER command
15.2.5. Connection Phase Packets
15.2.6. Capability Flags

The Connection Phase performs these tasks:

exchange the capabilities of client and server
setup SSL communication channel if requested
authenticate the client against the server

It starts with an initial handshake consisting of server sending Initial Handshake Packet and reading clients Handshake Response Packet. At this stage client can request SSL connection, in which case an SSL communication channel is established before client sends its authentication response.

After initial handshake, server informs client about the method to be used for authentication (unless it was already established during the handshake) and the authentication exchange continues until server either accepts connection by sending an OK_Packet or rejects it with ERR_Packet.

[D]

15.2.1. Initial Handshake

15.2.1.1. Plain handshake
15.2.1.2. SSL handshake
15.2.1.3. Capability negotiation
15.2.1.4. Determining authentication method

Initial Handshake starts with server sending the Initial Handshake Packet. After this, optionally, client can request an SSL connection to be established with SSL Connection Request Packet, and then client sends the Handshake Response Packet.

15.2.1.1. Plain handshake

server sending Initial Handshake Packet
client replying with Handshake Response Packet

[D]

15.2.1.2. SSL handshake

server sending Initial Handshake Packet
client replying with SSL Connection Request Packet
the ususal SSL exchange leading to establishing SSL connection
client sends Handshake Response Packet

[D]

15.2.1.3. Capability negotiation

To allow old client to connect to newer servers the initial handshake contains

the MySQL Server version
the server's and client's capabilities

They can agree on:

use of status flags
use of SQL states for error-codes
various other protocol extensions
authentication methods

Up to MySQL 4.0 the MySQL protocol only supported the Old Password Authentication, in MySQL 4.1 the Secure Password Authentication method was added and in MySQL 5.5 arbitrary authentication methods can be implemented by means of authentication plugins.

`CLIENT_PROTOCOL_41`	no	yes	yes	yes
`CLIENT_SECURE_CONNECTION`	--	no	yes	yes
`CLIENT_PLUGIN_AUTH`	--	--	no	yes
`Old Password Authentication`	x	x	x	x
`Secure Password Authentication`			x	x
Pluggable Authentication				x

If an account to which client tries to connect uses authentication method not supported by that client, server will refuse connection.

Todo. Verify that CLIENT_PLUGIN_AUTH does not matter when CLIENT_SECURE_CONNECTION is not set.

15.2.1.4. Determining authentication method

Method used for authentication is tied to the user acount and stored in the plugin column of mysql.user table. Client informs about the user account it wants to log into in the Handshake Response Packet. Only then server can look-up the mysql.user table and find the authentication method to be used.

However, to save some round-trips, server and client start authentication exchange already in the initial handshake using an optimistic guess of the authenticatio method to be used.

Server uses its default authentication method to produce intial authentication data payload and sends it to the client inside Initial Handshake Packet together with the name of the method used. Client can include in the Handshake Response Packet its reply to the authentication data sent by server.

When including authentication reply in the Handshake Response Packet, client is not obliged to use the same authentication method that was indicated by server in the Initial Handshake Packet. The name of the authentication method used by client is stored in the packet. If the guessed authentication method used either by the client or the server in the initial handshake was not correct, server informs client which authentication method should be used using Authentication Method Switch Request Packet (see Authentication Method Mismatch below).

If client or server do not support pluggable authentication (CLIENT_PLUGIN_AUTH capability flag is not set) then the authentication method used is inferred from cleint and server capabilities as follows:

The method used is Old Password Authentication if CLIENT_PROTOCOL_41 or CLIENT_SECURE_CONNECTION are not set.
The method used is Secure Password Authentication if both CLIENT_PROTOCOL_41 and CLIENT_SECURE_CONNECTION are set but CLIENT_PLUGIN_AUTH is not set.

15.2.2. Auth Phase Fast Path

15.2.2.1. Successful authentication
15.2.2.2. Authentication fails

Assume that client wants to log in as user U and that user account uses uthentication method M. The fast authentication path is used if both client and server used method M to generate authentication data in the initial handshake. In that case the first round of authentication has been already commenced during the handshake. Now, dependign on the authentication method, further authentication data can be exchanged until server either refuses or accepts connection.

15.2.2.1. Successful authentication

A succesful fast authentication path looks as follows:

the client connecting to the server
the server responds with the Initial Handshake Packet using auth method M
the client sends the Handshake Response Packet using the same method M
client and server possibly exchange further packets as required by authentication method M
the server responds with OK_Packet

[D]

The packets which server sends in step 4 are the Extra Authentication Data packet prefixed with 0x01, to distinguish them from the OK_Packet or ERR_Packet.

Note

Many authentication methods, including the native mysql password methods, consists of a single challenge--response exchange. In that case no extra packets are exchanged in step 4 and server sends OK_Packet directly after receiving Handshake Response Packet (provided that client is authorized).

15.2.2.2. Authentication fails

Server indicates that client is not allowed to connect by sending ERR_Packet. This can happen at any moment after initial handshake.

the client connecting to the server
the server responds with the Initial Handshake Packet
the client sends the Handshake Response Packet
client and server possibly exchange further packets as required by the authentication method used
the server responds with ERR_Packet and closes connection

[D]

Again, the Extra Authentication Data packets sent by server during step 4 start with 0x01 byte and thus can never be confused with the ERR_Packet.

15.2.3. Authentication Method Mismatch

15.2.3.1. Authentication method change
15.2.3.2. Insufficient client capabilities
15.2.3.3. New authentication method not known by client
15.2.3.4. non-CLIENT_PLUGIN_AUTH clients

Assume that client wants to log in as user U and that user account uses uthentication method M. If

server's default method used to generate authentication payload for Initial Handshake Packet was different than M, or
method used by client to generate authentication reply in Handshake Response Packet was different than M

then there is an authentication method missmatch and authentication exchange must be restarted using the correct authentication method.

Note

The missmatch can happen even if client and server used the same authentication method in the initial handshake, but this method was different from the method M required by the user account.
In the 4.1+ server the default authentication method is always Secure Password Authentication. For mysql client this is configurable with --default-auth option. Note hovewer, that as long as server uses Secure Password Authentication as its default method, there is no point in changing client's default authentication method to anything else. Doing so will always lead to method missmatch and the following authentication method switch request from server.
A sensibe thing to do for a client would be to see the server's default authentication method announced in the Initial Handshake Packet and try to use the same method for generating the Handshake Response Packet. However, this behavior is not yet implemented in the current mysql client library.

If authentication method missmatch happens, server sends to client the Authentication Method Switch Request Packet which contains the name of the authentication method to be used and the first authentication payload generated by the new method. Client should switch to the requested authentication method and continue exchange as dictated by that method. If client does not know the requested method it should disconnect.

15.2.3.1. Authentication method change

the client connecting to the server
the server responds with the Initial Handshake Packet
the client sends the Handshake Response Packet
the server responds with the Authentication Method Switch Request Packet to tell the client which authentication method to use.
client and server exchange further packets as required by the authentication method used
the server responds with OK_Packet or rejects connection with ERR_Packet.

[D]

15.2.3.2. Insufficient client capabilities

Server will reject connection with ERR_Packet if it discovers that client capabilities are not sufficient to complete authenticaiton. This can happen in the following situations:

A client which does not support pluggable authentication (CLIENT_PLUGIN_AUTH flag not set) connects to an account which uses authentication method different from Secure Password Authentication or Old Password Authentication.
A client which does not support secure authentication (CLIENT_SECURE_CONNECTION flag not set) connects to an account which uses authentication method different from Old Password Authentication.
Server's default authentication method used to generate authentication data in the Initial Handshake Packet is different from Secure Password Authentication and client does not support pluggable authentication (CLIENT_PLUGIN_AUTH flag not set).

In either of these cases authentication phase will look as follows:

the client connecting to the server
the server responds with the Initial Handshake Packet
the client sends the Handshake Response Packet
server recognizes that client does not have enough capabilities to handle required authentication method, sends ERR_Packet and closes connection.

[D]

15.2.3.3. New authentication method not known by client

Even if client supports external authentication (:mysql:flag`CLIENT_PLUGIN_AUTH` flag is set) the new authentication method indicated in the Authentication Method Switch Request Packet might be not know to it. In that case client simply disconnects.

the client connecting to the server
the server responds with the Initial Handshake Packet
the client sends the Handshake Response Packet
the server responds with the Authentication Method Switch Request Packet to tell the client which authentication method to use.
client discovers that it does not know the authentication method requested by server -- it disconnects.

[D]

15.2.3.4. non-CLIENT_PLUGIN_AUTH clients

The only situation where server will request authentication method change from a client which does not set CLIENT_PLUGIN_AUTH flag is when the following conditions hold:

the client connects to an account which uses Old Password Authentication.
the client supports secure authentication (CLIENT_SECURE_CONNECTION flag is set),
server's default authentication method is Secure Password Authentication.

In that case server sends Old Authentication Method Switch Request Packet. This packet does not contain new authentication mehtod name, which is implicitly assumed to be Secure Password Authentication, and it does not contain new authentication data. Client replies with Old Handshake Response Packet. To generate password hash client should re-use the random bytes sent by server in the Initial Handshake Packet.

[D]

15.2.4. Authentication after COM_CHANGE_USER command

15.2.4.1. COM_CHANGE_USER and non-CLIENT_PLUGIN_AUTH clients

During Command Phase a client can send a COM_CHANGE_USER command which will trigger logging into a new account, including the authentication handshake.

Similar to the initial authentication the server may reply with a OK_Packet or ERR_Packet for the usual fast-path or with a Authentication Method Switch Request Packet which contains the authentication method used for the new account and the first authentication data payload to be consumed by the client. Further handshake continues as usual, as defined by the authentication method being used. Eventually server will accept new account with OK_Packet and resume the command phase or it will reject change with ERR_Packet and disconnect.

the client sends COM_CHANGE_USER packet
the server responds with the Authentication Method Switch Request Packet which initiates authentication handshake using the correct authentication method
client and server exchange further packets as required by the authentication method used
the server responds with OK_Packet and returns to command phase or ERR_Packet and closes the connection

[D]

15.2.4.1. COM_CHANGE_USER and non-CLIENT_PLUGIN_AUTH clients

Clients which do not support pluggable authentication can send COM_CHANGE_USER command for accounts which use Secure Password Authentication or Old Password Authentication. In this case it is assumed that server has already sent the authentication challenge - the same which was sent when the client connected for the first time - and client's reply to that challenge, i.e. the hash of the new password, should be sent in the auth-response field of COM_CHANGE_USER packet.

the client sends COM_CHANGE_USER packet with authentication response (hash of a password) for Secure Password Authentication (post 4.1 clients) or Old Password Authentication (pre 4.1 clients) method.
the server responds with OK_Packet and returns to command phase or with ERR_Packet and closes the connection.

[D]

As during normal connection, it is also possible that a post 4.1 client which does not support pluggable authentication connects to an account which uses Old Password Authentication. In that case server will send Old Authentication Method Switch Request Packet and expect client to reply with Old Handshake Response Packet.

the client sends COM_CHANGE_USER packet with response for Secure Password Authentication method
the server replies with Old Authentication Method Switch Request Packet (0xFE byte)
the client sends response again, this time in the form required by Old Password Authentication method
the server responds with OK_Packet and returns to command phase or ERR_Packet and closes the connection.

[D]

15.2.5. Connection Phase Packets

Protocol::Handshake:

Initial Handshake Packet

When the client connects to the server the server sends a handshake packet to the client. Depending on the server version and configuration options different variants of the initial packet are sent.

To allow the server to add support for newer protocols the first byte defines the protocol version.

Since 3.21.0 the Protocol::HandshakeV10 is sent, while it was still supporting Protocol::HandshakeV9 with a compile time option.

Payload

1              protocol_version
...

Protocol::HandshakeV10:

Initial Handshake Packet - protocol version 10

Payload

1              [0a] protocol version
string[NUL]    server version
4              connection id
string[8]      auth-plugin-data-part-1
1              [00] filler
2              capability flags (lower 2 bytes)
  if more data in the packet:
1              character set
2              status flags
2              capability flags (upper 2 bytes)
  if capabilities & CLIENT_PLUGIN_AUTH {
1              length of auth-plugin-data
  } else {
1              [00]
  }
string[10]     reserved (all [00])
  if capabilities & CLIENT_SECURE_CONNECTION {
string[$len]   auth-plugin-data-part-2 ($len=MAX(13, length of auth-plugin-data - 8))
  if capabilities & CLIENT_PLUGIN_AUTH {
    if version >= (5.5.7 and < 5.5.10) or (>= 5.6.0 and < 5.6.2) {
string[EOF]    auth-plugin name
    } elseif version >= 5.5.10 or >= 5.6.2 {
string[NUL]    auth-plugin name
    }
  }

Fields

protocol_version (1) -- 0x0a protocol_version
server_version (string.NUL) -- human-readable server version
connection_id (4) -- connection id
auth_plugin_data_part_1 (string.fix_len) -- [len=8] first 8 bytes of the auth-plugin data
filler_1 (1) -- 0x00
capability_flag_1 (2) -- lower 2 bytes of the Protocol::CapabilityFlags (optional)
character_set (1) -- default server character-set, only the lower 8-bits Protocol::CharacterSet (optional)
status_flags (2) -- Protocol::StatusFlags (optional)
capability_flags_2 (2) -- upper 2 bytes of the Protocol::CapabilityFlags (since MySQL Server 5.5.7)
auth_plugin_data_len (1) -- length of the combined auth_plugin_data, if auth_plugin_data_len is > 0
auth_plugin_name (string.NUL) -- name of the auth_method that the auth_plugin_data belongs to

Note
Due to Bug#59453 the auth-plugin-name is missing the terminating NUL-char in versions prior to 5.5.10 and 5.6.2.

Returns

Protocol::HandshakeResponse from the client

Implemented by

send_server_handshake_packet()

Example

36 00 00 00 0a 35 2e 35    2e 32 2d 6d 32 00 0b 00    6....5.5.2-m2...
00 00 64 76 48 40 49 2d    43 4a 00 ff f7 08 02 00    ..dvH@I-CJ......
00 00 00 00 00 00 00 00    00 00 00 00 00 2a 34 64    .............*4d
7c 63 5a 77 6b 34 5e 5d    3a 00                      |cZwk4^]:.

Note

The auth-plugin-data is the concatenation of strings auth-plugin-data-part-1 and auth-plugin-data-part-2.

New in 3.21.x(x ≥ 0 && x < .17a)

Note

Only the fields up to the filler after the auth_plugin_data_part_1 are required, all other fields are optional.

Protocol::HandshakeV9:

Initial Handshake Packet - Protocol Version 9

Payload

1              [09] protocol_version
string[NUL]    server_version
4              connection_id
string[NUL]    scramble

Fields

protocol_version (1) -- 0x09 protocol_version
server_version (string.NUL) -- human-readable server version
connection_id (4) -- connection id
auth_plugin_data (string.NUL) -- auth plugin data for Authentication::Old

Returns

Protocol::HandshakeResponse320

New in 3.20.x

Deprecated in 3.21.xremoved in 3.22.0

Protocol::HandshakeResponse:: Depending on the servers support for the CLIENT_PROTOCOL_41 capability and the clients understanding of that flag the client has to send either a Protocol::HandshakeResponse41 or Protocol::HandshakeResponse320.

Protocol::HandshakeResponse41:

Handshake Response Packet sent by 4.1+ clients supporting CLIENT_PROTOCOL_41 capability, if the server announced it in its Initial Handshake Packet. Otherwise (talking to an old server) the Protocol::HandshakeResponse320 packet has to be used.

Payload

4              capability flags, CLIENT_PROTOCOL_41 always set
4              max-packet size
1              character set
string[23]     reserved (all [0])
string[NUL]    username
  if capabilities & CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA {
lenenc-int     length of auth-response
string[n]      auth-response
  } else if capabilities & CLIENT_SECURE_CONNECTION {
1              length of auth-response
string[n]      auth-response
  } else {
string[NUL]    auth-response
  }
  if capabilities & CLIENT_CONNECT_WITH_DB {
string[NUL]    database
  }
  if capabilities & CLIENT_PLUGIN_AUTH {
string[NUL]    auth plugin name
  }
  if capabilities & CLIENT_CONNECT_ATTRS {
lenenc-int     length of all key-values
lenenc-str     key
lenenc-str     value
   if-more data in 'length of all key-values', more keys and value pairs
  }

Fields

capability_flags (4) -- capability flags of the client as defined in Protocol::CapabilityFlags
max_packet_size (4) -- max size of a command packet that the client wants to send to the server
character_set (1) -- connection's default character set as defined in Protocol::CharacterSet.
username (string.fix_len) -- name of the SQL account which client wants to log in -- this string should be interpreted using the character set indicated by character set field.
auth-response (string.NUL) -- opaque authentication response data generated by Authentication Method indicated by the plugin name field.
database (string.NUL) -- initail database for the connection -- this string should be interpreted using the character set indicated by character set field.
auth plugin name (string.NUL) -- the Authentication Method used by the client to generate auth-response value in this packet. This is an UTF-8 string.

Example

On MySQL 5.5.8 with CLIENT_PROTOCOL_41 CLIENT_PLUGIN_AUTH, CLIENT_SECURE_CONNECTION, and CLIENT_CONNECT_WITH_DB set, it may look like:

54 00 00 01 8d a6 0f 00    00 00 00 01 08 00 00 00    T...............
00 00 00 00 00 00 00 00    00 00 00 00 00 00 00 00    ................
00 00 00 00 70 61 6d 00    14 ab 09 ee f6 bc b1 32    ....pam........2
3e 61 14 38 65 c0 99 1d    95 7d 75 d4 47 74 65 73    >a.8e....}u.Gtes
74 00 6d 79 73 71 6c 5f    6e 61 74 69 76 65 5f 70    t.mysql_native_p
61 73 73 77 6f 72 64 00                               assword.

Caution

Currently multibyte character sets such as UCS2, UTF16 and UTF32 are not supported.

Note

If client wants to have a secure SSL connection and sets CLIENT_SSL flag it should first send the SSL Request Packet and only then, after establishing the secure connection, it should send the Handshake Response Packet.

Protocol::HandshakeResponse320:

Old Handshake Response Packet used by old clients or if the server doesn't support CLIENT_PROTOCOL_41 capability.

Payload

2              capability flags, CLIENT_PROTOCOL_41 never set
3              max-packet size
string[NUL]    username
  if capabilities & CLIENT_CONNECT_WITH_DB {
string[NUL]    auth-response
string[NUL]    database
  } else {
string[EOF]    auth-response
  }

Fields

capability_flags (2) -- capability flags of the client as defined in Protocol::CapabilityFlags
max_packet_size (3) -- max size of a command packet that the client wants to send to the server
auth-response (string.NUL) -- opaque authentication response data generated by Authentication Method indicated by the plugin name field.
database (string.NUL) -- initail database for the connection -- this string should be interpreted using the character set indicated by character set field.

Example

11 00 00 01 85 24 00 00    00 6f 6c 64 00 47 44 53    .....$...old.GDS
43 51 59 52 5f                                        CQYR_

Note

if auth-response field is followed by a database field it has to be 0-terminated.

Protocol::SSLRequest:

SSL Connection Request Packet. It is like Handshake Response Packet but is truncated right before username field. If server supports CLIENT_SSL capability, client can send this packet to request a secure SSL connection. The CLIENT_SSL capability flag must be set inside the SSL Connection Request Packet.

Payload

4              capability flags, CLIENT_SSL always set
4              max-packet size
1              character set
string[23]     reserved (all [0])

Protocol::AuthSwitchRequest:

Authentication Method Switch Request Packet. If both server and client support CLIENT_PLUGIN_AUTH capability, server can send this packet to ask client to use another authentication method.

Payload

1              [fe]
string[NUL]    plugin name
string[EOF]    auth plugin data

Fields

status (1) -- 0xfe
auth_method_name (string.NUL) -- name of the authentication method to switch to
auth_method_data (string.EOF) -- initial auth-data for that authentication method

Returns

Protocol::AuthSwitchResponse or connection close

Example

If CLIENT_PLUGIN_AUTH was set and the server wants the client to authenticate with the Authentication::Native41 method it sends:

2c 00 00 02 fe 6d 79 73    71 6c 5f 6e 61 74 69 76    ,....mysql_nativ
65 5f 70 61 73 73 77 6f    72 64 00 7a 51 67 34 69    e_password.zQg4i
36 6f 4e 79 36 3d 72 48    4e 2f 3e 2d 62 29 41 00    6oNy6=rHN/>-b)A.

Protocol::OldAuthSwitchRequest:

Old Authentication Method Switch Request Packet consisting of a single 0xfe byte. It is sent by server to request client to switch to Old Password Authentication if CLIENT_PLUGIN_AUTH capability is not supported (by either the client or the server)

Payload

1     [fe]

Fields

status (1) -- 0xfe

Returns

Protocol::AuthSwitchResponse with old password hash

Example

01 00 00 02 fe

Protocol::AuthSwitchResponse:

Authentication Method Switch Response Packet which contains response data generated by the authenticatication method requested in Authentication Method Switch Request Packet. This data is opaque to the protocol.

Payload

string[EOF]    auth plugin response

Fields

data (string.EOF) -- authentication response data

Returns

Protocol::AuthMoreData or OK_Packet or ERR_Packet

Example

If the client sends a mysql_native_password response, but the server has a mysql_old_password for that user, it will ask the client to switch to mysql_old_password and client would reply with:

09 00 00 03 5c 49 4d 5e    4e 58 4f 47 00             ....\IM^NXOG.

Protocol::AuthMoreData:

Payload

1              [01]
string[EOF]    plugin data

Fields

status (1) -- 0x01
auth_method_data (string.EOF) -- extra auth-data beyond the initial challenge

15.2.6. Capability Flags

The capability flags are used by the client and server to indicate which features they support and want to use.

Protocol::CapabilityFlags:

CLIENT_LONG_PASSWORD

Use the improved version of Old Password Authentication

Note

assumed to be set since 4.1.1

Value: 0x00000001

New in 3.21.x(x < 17)

Deprecated in 4.1.1

CLIENT_FOUND_ROWS

Send found rows instead of affected rows in EOF_Packet

Value: 0x00000002

New in 3.21.x(x < 17)

CLIENT_LONG_FLAG

Longer flags in Protocol::ColumnDefinition320

Value: 0x00000004
Server: supports longer flags
Client: expects longer flags

New in 3.21.20

Deprecated in 4.1

CLIENT_CONNECT_WITH_DB

One can specify db on connect in Handshake Response Packet

Value: 0x00000008
Server: supports schema-name in Handshake Response Packet
Client: Handshake Response Packet contains a schema-name

New in 3.21.26

CLIENT_NO_SCHEMA

Value: 0x00000010
Server: Don't allow database.table.column

New in 3.21.x(x > 29 && x < 33b)

CLIENT_COMPRESS

Compression protocol supported

Value: 0x00000020
Server: supports compression
Client: switches to Compression compressed protocol after successful auth

New in 3.22.3

CLIENT_ODBC

Value: 0x00000040

Special handling of ODBC behaviour

Note

no special behaviour since 3.22

New in 3.22.4

CLIENT_LOCAL_FILES

Can use LOAD DATA LOCAL

Value: 0x00000080
Server: allows the LOCAL INFILE request of LOAD DATA|XML
Client: will handle LOCAL INFILE request

New in 3.22.6

CLIENT_IGNORE_SPACE

Value: 0x00000100
Server: parser can ignore spaces before '('
Client: let the parser ignore spaces before '('

New in 3.22.7

CLIENT_PROTOCOL_41

Value: 0x00000200
Server: supports the 4.1 protocol
Client: uses the 4.1 protocol

New in 4.1.1

Note

this value was CLIENT_CHANGE_USER in 3.22, unused in 4.0

CLIENT_INTERACTIVE

wait_timeout vs. wait_interactive_timeout

Value: 0x00000400
Server: supports interactive and non-interactive clients
Client: client is interactive
See: http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html

New in 3.22.29

CLIENT_SSL

Value: 0x00000800
Server: supports SSL
Client: switch to SSL after sending the capability-flags

New in 3.23

CLIENT_IGNORE_SIGPIPE

Value: 0x00001000
Client: Don't issue SIGPIPE if network failures (libmysqlclient only)
See: http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html

New in 3.23

CLIENT_TRANSACTIONS

Value: 0x00002000
Server: can send status flags in EOF_Packet
Client: expects status flags in EOF_Packet

Note

this flag is optional in 3.23, but set all the time by the server since 4.0

New in 3.23

CLIENT_RESERVED

unused

Value: 0x00004000

Note

Was named CLIENT_PROTOCOL_41 in 4.1.0

New in 4.1.0

Deprecated in 4.1.1

CLIENT_SECURE_CONNECTION

Value: 0x00008000
Server: supports Authentication::Native41
Client: supports Authentication::Native41

New in 4.1.1

CLIENT_MULTI_STATEMENTS

Value: 0x00010000
Server: can handle multiple statements per COM_QUERY and COM_STMT_PREPARE
Client: may send multiple statements per COM_QUERY and COM_STMT_PREPARE

Note

was named CLIENT_MULTI_QUERIES in 4.1.0, renamed later

Requires: CLIENT_PROTOCOL_41

CLIENT_MULTI_RESULTS

Value: 0x00020000
Server: can send multiple resultsets for COM_QUERY
Client: can handle multiple resultsets for COM_QUERY
Requires: CLIENT_PROTOCOL_41

CLIENT_PS_MULTI_RESULTS

Server: can send multiple resultsets for COM_STMT_EXECUTE
Client: can handle multiple resultsets for COM_STMT_EXECUTE
Value: 0x00040000
Requires: CLIENT_PROTOCOL_41

CLIENT_PLUGIN_AUTH

Value: 0x00080000
Server: supports more fields in
Client: supports auth plugins
Requires: CLIENT_PROTOCOL_41

New in 5.5.7

CLIENT_CONNECT_ATTRS

Value: 0x00100000
Server: allows connection attributes in Protocol::HandshakeResponse41
Client: sends connection attributes in Protocol::HandshakeResponse41

New in 5.6.6

CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA

Value: 0x00200000
Server: understands length encoded integer for auth response data in Protocol::HandshakeResponse41
Client: length of auth response data in Protocol::HandshakeResponse41 is a length encoded integer

New in 5.6.7

Note

the flag was introduce in 5.6.6, but had the wrong value.

Top / Previous / Next / Up / Table of Contents