I've given it a quick look-thru and I. Am. Impressed. This is more Super Cool Mojo!
> On Mar 12, 2016, at 10:46 AM, Graham Leggett <[email protected]> wrote: > > 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>
