Hi all, The following patch provides support for TCP proxying to httpd.
It consists of the following three parts: - mod_tcp: Allows the frontend to receive pure TCP connections - mod_proxy_tcp: Allows the proxy to make pure tcp or tls connections to a backend - mod_ssl_tcp: Allows the proxy to route incoming connections based on the SNI header (tlsext) In the following example config, incoming TCP connections are routed based on their SNI (the tlsext protocol) to given backend servers, which then complete the SSL connections as raw tunnels. This allows you to use client certificates through the httpd proxy balancer all the way to the backend server without the proxy terminating any SSL along the way. <VirtualHost localhost:9000> Protocol tlsext ServerName jira.example.com ProxyPass / tcp://john.example.com:443 </VirtualHost> <VirtualHost localhost:9000> Protocol tlsext ServerName www.example.com ProxyPass / tcp://erica.example.com:443 </VirtualHost> In order for mod_ssl_tcp to work, it needs to read ahead to see if any client hello message is present, and then set aside any extra data so it could be read again. This is fundamentally incompatible with c->data_in_input_filters which only allows the core filter to set aside unread data. For this reason the ability to set aside data was rolled out to all filters. mod_ssl_tcp just cares about SNI for now, but could conceivably support APLN too, making a configuration something like this: <VirtualHost localhost:9000> Protocol tlsext ServerName secure.example.com <Protocol imap> ProxyPass / tcp://imap.example.com:993 </Protocol> <Protocol pop> ProxyPass / tcp://pop3.example.com:995 </Protocol> </VirtualHost> Regards, Graham --
httpd-tcp-proxy.patch
Description: Binary data