If the client is first to send during the SSL startup protocol, then
there's no problem: there can only be one byte waiting for us.
So it looks good from the SSL perspective.
--
Fabien Coelho - [EMAIL PROTECTED]
---(end of broadcast)---
TIP 1:
On N, 2004-09-23 at 06:41, Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
We were bitten by the following bug a few times, when our server tried
to reestablish connections under bad network conditions:
if connection is closed while trying to get response to SSL setup packet
Hannu Krosing [EMAIL PROTECTED] writes:
One possibility is to forget the direct call to recv() and use
pqReadData --- since conn-ssl isn't set yet, and we aren't expecting
the server to send more than one byte, this should in theory be safe.
I was scared by the comment before recv(...,1,0)
Dear Tom,
When I wrote that, I was trying to assume as little as possible about
the SSL protocol. The only way there could be a problem is if the
server is first to send during the SSL negotiation handshake; which
seems odd but not impossible. Anyone know for sure?
As for the RFC, the
Fabien COELHO [EMAIL PROTECTED] writes:
Now if you connect to some other server with some other protocol, that is
another issue...
But the code in question is only for SSL connection to PG, so that's
a red herring I think.
Also, I do not know how the postgresql protocol interacts
with SSL...
We were bitten by the following bug a few times, when our server tried
to reestablish connections under bad network conditions:
if connection is closed while trying to get response to SSL setup packet
(i.e. conn-status is CONNECTION_SSL_STARTUP), we get a busy loop, as
line 1035 in 8.0.0.beta2:
Hannu Krosing [EMAIL PROTECTED] writes:
We were bitten by the following bug a few times, when our server tried
to reestablish connections under bad network conditions:
if connection is closed while trying to get response to SSL setup packet
(i.e. conn-status is CONNECTION_SSL_STARTUP), we get
