> > As it is right now, it should work in all combinations except a 6.6
client
> > compiled with SSL support connecting to a pre-6.6 server. It already
> > falls-back if the server is 6.6 (without SSL support). And the 6.6
client
> > compiled without SSL works.
> 
> 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.

Not quite.
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)).


//Magnus

Sat, 24 Jul 1999 19:38:37 +0200
Magnus Hagander <mha@sollentuna.net>
RE: [HACKERS] Re: SSL patch 
Magnus Hagander <mha@sollentuna.net> writes:
>> 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.

			regards, tom lane

Sat, 24 Jul 1999 13:57:48 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Re: SSL patch 