Ruediger Pluem wrote: > My point in the previous mail was that using the connection interface for > this purpose imposes some problems with pool lifetimes, allocators and the > pre connection hook and that there might be more elegant and clearer > solutions for the *HTTP* backend via the means of a HTTP client library > like serf.
I disagree, trying to use a completely separate client library as a bandaid to avoid problems that should simply be fixed is not the correct longterm solution. The backend connection uses a connection because it works the same way as the frontend connection. Because of this, we get the ability to use the httpd plugins mechanism to extend the backend connection just as we can extend the frontend connection, and the key module that has done this for us to date is mod_ssl. If we used a completely different client library for the backend, we would need to use that library's functions and procedures to solve problems like SSL, and that means functionality that either duplicates or competes with functionality on the frontend, and that is really ugly. Imagine if an admin wanted to deploy Mozilla NSS on the frontend, but the proxy client library only supported openssl. Should the server bind to two competing crypto implementations? Of course not. Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
