Re: Disable OpenSSL compression
От | Albe Laurenz |
---|---|
Тема | Re: Disable OpenSSL compression |
Дата | |
Msg-id | D960CB61B694CF459DCFB4B0128514C2071A0DF7@exadv11.host.magwien.gv.at обсуждение исходный текст |
Ответ на | Re: Disable OpenSSL compression (Christopher Browne <cbbrowne@gmail.com>) |
Ответы |
Re: Disable OpenSSL compression
|
Список | pgsql-hackers |
Christopher Browne wrote: >> I think that JDBC and Npgsql should also support disabling compression. > > That's the *real* problem here... > > You're quite right that if we allow controlling this on the libpq > side, it is surely desirable to allow controlling this via JDBC, > Npgsql, and other mechanisms people may have around. [...] > With that series of complications, I wonder if maybe the right place > to control this is pg_hba.conf. I think that wouldn't work, because to query pg_hba.conf, you have to know user and database, which come from the client side. But the SSL negotiation takes place earlier, namely when the connection is established. > I wonder how many SSL parameters there are which would be worth trying > to have available. I expect we'd benefit from looking at all the > relevant ones at once, so as to not have the problem of hacking "one > more" into place and perhaps doing it a bit differently each time. Sure, if anybody can think of any. A quick look at "man SSL_CTX_set_options" didn't show me any, but then OpenSSL's documentation is very bad (the page does not even mention SSL_OP_NO_COMPRESSION) and I am no SSL expert. Is the following proposal acceptable: - Add a GUC ssl_compression, defaulting to "on". - Add a client option "sslcompression" and an environment variable PGSSLCOMPRESSION, defaulting to "1". Compression will be disabled if either side refuses. That way you can control the setting per client, but you can also force it on clients that do not use libpq if you want. Yours, Laurenz Albe
В списке pgsql-hackers по дате отправления: