Re: Direct SSL connection and ALPN loose ends
От | Jacob Champion |
---|---|
Тема | Re: Direct SSL connection and ALPN loose ends |
Дата | |
Msg-id | CAOYmi+nwvu21mJ4DYKUa98HdfM_KZJi7B1MhyXtnsyOO-PB6Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Direct SSL connection and ALPN loose ends (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Direct SSL connection and ALPN loose ends
|
Список | pgsql-hackers |
On Mon, Apr 29, 2024 at 8:24 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > I was mostly worried about the refactoring of the > retry logic in libpq (and about the pre-existing logic too to be honest, > it was complicated before these changes already). Some changes in the v17 negotiation fallback order caught my eye: 1. For sslmode=prefer, a modern v3 error during negotiation now results in a fallback to plaintext. For v16 this resulted in an immediate failure. (v2 errors retain the v16 behavior.) 2. For gssencmode=prefer, a legacy v2 error during negotiation now results in an immediate failure. In v16 it allowed fallback to SSL or plaintext depending on sslmode. Are both these changes intentional/desirable? Change #1 seems to partially undo the decision made in a49fbaaf: > Don't assume that "E" response to NEGOTIATE_SSL_CODE means pre-7.0 server. > > These days, such a response is far more likely to signify a server-side > problem, such as fork failure. [...] > > Hence, it seems best to just eliminate the assumption that backing off > to non-SSL/2.0 protocol is the way to recover from an "E" response, and > instead treat the server error the same as we would in non-SSL cases. Thanks, --Jacob
В списке pgsql-hackers по дате отправления: