> >> Actually, it shouldn't matter whether the server is 6.6-without-SSL
> >> or pre-6.6. At least in the way I envisioned it, they'd act the same.
>
> > The 6.6-without-SSL still knows about the NEGOTIATE_SSL_CODE packet that
is
> > sent, and can respond "No, I can't do SSL". The pre-6.6 does not know
about
> > the existance of this packet, and will thus respond with "Unsupported
> > Frontend Protocol" (since it's a normal StartupPacket with the version
> > number set to something very large (like the cancel request was
> > implemented)).
>
> OK, the point being that then the client can either break the connection
> (if it doesn't want to do an insecure connection) or send a
> StartupPacket to continue with an insecure connection. I agree this
> will be a little quicker than tearing down the connection and starting
> a new one, which is what must happen in the case of an old server.
>
> But you could save some code on both sides if you just made the
> teardown/new connection behavior the only path for falling back to
> non-SSL. I'm not sure that SSL-enabled-client-talking-to-6.6-but-
> not-SSL-enabled-server will be a sufficiently common scenario to
> justify a lot of extra code to make it a tad faster. You'd expect
> that most installations will have SSL at the server if they have
> it anywhere.
>
> If it's only a small amount of extra code then it doesn't matter,
> of course. I'm just dubious that it's worth taking extra care
> for that case when you are going to have the other case anyway.
Well. There is almost no extra code. The code has to be in place anyway, to
deal with those clients that do support SSL. It's just a matter of the
server sending a single character (a 'N' to say normal, non-SSL connection)
to the client after receiving the special packet that it knows about. It's
just:
#ifdef USE_SSLSSLok = 'S';
#elseSSLok = 'N';
#endif
SSLok is then sent to the client. This code is only executed if the client
first asked for SSL - if it's a non-SSL client, this whole phase is skipped.
All the rest of the code is shared between the SSL and the non-SSL case.
I'll post a patch to the patches-list that makes the client work with a
pre-6.6 server in a minute. The noticable thing being that each time this
client tries to connect, the server logs an "Unsupported frontent protocol"
message. The client will then tear down it, and the connectDB() function
will call itself while being instructed to run with the pre-6.6 protocol. It
works fine for me to connect to a 6.4.2 server.
//Magnus