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: subscr
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 S
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
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(..
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 pa
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 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:
