Hi, Lenski,, On Jun 30, Lenski, Daniel wrote:
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...
Yes
(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.
Agree. I just meant that there're two questions. What to send. And how to send. And that MDEV-15935 was mainly about "how". But it'd be better if it would implement a simple answer to "what" too, like that very limited URI of the form mysql://host[:port]
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.
That's why it's not part of MDEV-15935 :)
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."
It calls a "connection plugin" for that. And at the first glance it looks like the only connection plugin is replication, it I'd assume that Connector/C can understand URI in the form of replication://..... Anyway, Connector/C has the support for URIs and adding a "mysql" connection plugin is not only possible, it'll fit in nicely into the existing code, there's place for it already.
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.
Yes. Also because FederatedX and mysqljs use somewhat different set of parameters, so why should it follow JDBC URI specs? We need to do this "complex undertaking" first and write some specs for the URI format. For now it seems we both agree that it's better to keep it minimal.
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 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.
Oh, I'm sorry, I didn't mean that. I didn't mean that the server needs to implement or track anything at all. What I was saying - if the server will send this advisory redirection message and then continue its normal shutdown process, it'll inevitably disconnect every client anyway. That is, either way the client gets a redirection message and then gets disconnected.
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?
I don't really know. Judging from the profile of the first contributor it seems like something they need in Azure. But I know nothing about Azure internals, so cannot say why.
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?
well, I just don't think I know more than users about their application. If someone would explain why they need advisory redirection, I might be able to argue that they actually need forceful redirection. But as long as I cannot, I have to assume that advisory redirection is what users need. Instead of trying to invent a solution for a problem that I don't know. Ideally we'd have both, of course. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org