From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Hannu Krosing <hannu(at)tm(dot)ee>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BUG: possible busy loop when connection is closed while trying to establish SSL connection |
Date: | 2004-09-23 16:14:39 |
Message-ID: | 26913.1095956079@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> 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... I guess the server waits for the first packet to decided
> whether it is a SSL connection or a non-SSL connection?
It's
Client sends SSL request message
Server sends back 1 byte indicating if it can do SSL or not
<< SSL startup protocol happens here >>
Client sends normal PG connection request message
Authentication exchange proceeds as usual
If the server were first to send during the SSL startup protocol, then
it's possible that more than one byte would be waiting for the client
when it reads the server response. We'd have no easy way to "push back"
those bytes and allow them to be re-read by the client-side SSL library.
So that was the danger I was concerned about.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-09-23 16:40:41 | Re: SQL-Invoked Procedures for 8.1 |
Previous Message | Tom Lane | 2004-09-23 16:05:54 | Re: Use of zlib |