On Fri, 2023-06-30 at 13:29 +0200, Sergei Golubchik wrote:
There was an original pull request from ~5 years ago, but then the contributor disappeared and I didn't want to do anything until they'd at least confirm that the new suggested approach works for them Are you referring to this Connector/J PR, which attempted to add client-side parsing of a redirection string in a URL-ish format? https://github.com/mariadb-corporation/mariadb-connector-j/pull/134/files#di...
(1) Redirection targets in "URL" format will be extremely difficult to support in consistent and secure ways across client implementations.
MDEV-15935 itself (the server part) does not specify what the URL should look like, it's only about passing basically an arbitrary string to the client.
Giving the server the ability to passing "an arbitrary string" to the client will create many more problems than it will solve, if there is no agreement for how the client software should interpret that string. If the server can send a redirect string that looks something like "mysql://UserB@other-server.company.com:3306/my_database?ttl=10&user=UserA" (as proposed in the stale Connector/J PR), but Connector/C ignores the query parameter fields including the username, and Connector/J misinterprets UserB as part of the hostname… that’s chaos, not a solution.
Although the original PR used URLs, Federated uses URLs, Connector/J uses URLs - it's de facto very common already. It might be good to standardize the URL format and use it everywhere.
Agreed. However, this is a complex undertaking, and older/non-standard URL formats WILL continue to proliferate if existing clients and servers continue to accept them or silently ignore them.
The Connector/C library currently has no ability to parse connection "URLs" in either the Connector/J (https://mariadb.com/kb/en/about-mariadb-connector-j) or the MySQL formats ( https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-jdbc-url-...), which are partially but fully compatible with each other, and to my knowledge there is no formal definition of either. As far as I know, Connector/C is the basis for most higher-level languages’ connector libraries (e.g. Connector/Python).
Not quite. Connector/C can parse both DSN format (key=value pairs, semicolon-separated) and URI format, See https://github.com/mariadb-corporation/mariadb-connector-c/blob/5af90f00ff/l... and https://github.com/mariadb-corporation/mariadb-connector-c/blob/5af90f00ff/l...
although the latter cannot be used for normal connections yet, which is good, becayse without standard URI syntax it would've definitely been incompatible with everything.
All that the second snippet appears to show is that Connector/C can look for "://" in a string; as you say, it "cannot be used for normal connections yet." This does not mean that it can parse a string like "jdbc:mysql://mariadb.server.com:3306/defaultDB?characterEncoding=latin1" and set all of its relevant internal state in a way that's equivalent to what Connector/J does. Because of this, it would be inadvisably premature to ALLOW servers to SEND a JDBC URL like that as a redirection target, since we cannot expect various client software/libraries to be able handle that URL in a consistent way. Compare this with HTTP 3xx redirection, which has very well-defined semantics in terms of caching, HTTP methods, etc (summarized in https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx) . Because of that servers can generally rely on clients to follow redirection instructions in a consistent way.
Right, that's why I moved URI topic out of MDEV-15935, making the latter only about "how to pass <arbitrary string> to the client"
There are two common approaches to a connection string - let's call them "JDBC way" (that's URI) and "ODBC way" (semicolon separated key=value pairs). mysqljs uses URI, Perl DBI uses DSN, PHP PDO uses DSN, Federated engine uses URI, etc.
I'd really rather avoid introducing a new connection string format.
Agreed, not introducing a new format makes sense.
MDEV-15935 says that we "might" optionally implement URI validation in the server. Without it one can literally send an arbitrary string. This might be error-prone. With the server side URI validation we can limit redirection URIs to "mysql://host[:port]" which basically is what you wanted and postpones all the URI complexity till we have some standard specs for it.
I'd be happy to modify my PRs to only allow SERVER_REDIRECT_TARGET of the form "mysql://host[:port]", to avoid introducing a new format.
This "advisory" redirection would seem to be greatly limited in the kind of use cases it supports. If servers sending redirection information can't RELY ON clients disconnecting from them, then they can't use redirection as a prelude to shutting down the server.
Of course, they can. The idea is to tell clients to connect to another server and to disconnect them after that. If redirection is forced, then the server will send a "redirection error" and disconnect. If redirection is advisory, the server will send a redirection info and disconnect few seconds later when it shuts down.
That would be substantially more complex to implement. If the server can simply send an error packet that says "Go somewhere else" and then disconnect the client, it doesn't need to track any further information on the connection. If the server needs to send an advisory packet that says "Please go somewhere else or I'll disconnect you in 15 seconds", and then continue handling that connection as normal, and then interrupt and disconnect it 15 seconds later… that requires a lot more state tracking. (What happens if the client starts a long-running query, or does some non-transactional DDL, or does anything with a non- transactional, non-crash-safe engine?)
Anyway, in the original proposal (from ~5 years ago) it was advisory, apparently it's what the user needed.
But WHY did the user need that? What are the use cases for "advisory-ONLY" redirection? Does it make sense to design and implement this feature be based on what one user thought would be useful 5 years ago, rather than basing it on a stateless redirection model that has been successfully used in HTTP for 25+ years? Thanks, Daniel Lenski Amazon RDS MySQL/MariaDB engine team