The idea is to make the configuration of the protocols (TCP, HTTP, HTTPS, MySQL, etc) and the ports to listen more flexible.

1. It should be possible to specify a custom list of listen_host and listen_port for every protocol.
2. A protocol can be listed multiple times in the config (with different settings).
3. Default user and database can be overridden in every protocol entry.
4. It should be possible to configure different TLS certificates for different protocols.
5. It should be possible to configure TLS and PROXYv1 as wrappers on top of other protocols, e.g. enable PROXYv1 on top of TLS on top of HTTP.
6. Allow configuring IP filtering for every protocol.

Use case

Examples:

• allow TCP protocol without TLS on localhost with the default user named "root" and allow TCP with TLS for internet with the default user named "default";
• bind server to multiple network interfaces, but also on different ports;
• wrap HTTP protocol under PROXYv1 protocol;
• use different ports for user queries and internal communication for distributed queries.

Describe the solution you'd like

A hierarchical configuration where one protocol can be built on top of the parameters of another protocol.
Example:

<protocols>
    <http>
        <type>http</type>
        <listen>
            <host>::</host>
            <port>8081</port>
        </listen>
    </http>
    <http_proxy>
        <type>proxy_v1</type>
        <impl>
            <type>http</type>
        </impl>
        <listen>
            <host>::</host>
            <port>8081</port>
        </listen>
        <default_database>test</default_database>
    </http_proxy>
...

Details

Old-style configuration should remain to be available.
The global listen_host and listen_port configuration should be used as a default for the new configuration.
The types https, tcp_secure and similar should be available as shortcuts of more explicit configuration (tls on top of http).
The protocols for embedded Keeper can be specified inside its configuration but with the same style.

Notes

MySQL and PostgreSQL protocols are using a different approach for TLS. Instead of transparent wrapping of the protocol in TLS after connection, they are doing TLS handshake after negotiating the protocol. It means, they cannot be presented as TLS over an unencrypted protocol.