Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 46238 invoked from network); 13 Sep 2009 20:39:10 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Sep 2009 20:39:10 -0000 Received: (qmail 61907 invoked by uid 500); 13 Sep 2009 20:39:09 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 61829 invoked by uid 500); 13 Sep 2009 20:39:09 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 61820 invoked by uid 99); 13 Sep 2009 20:39:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Sep 2009 20:39:09 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Sun, 13 Sep 2009 20:39:06 +0000 Received: (qmail 45872 invoked by uid 2161); 13 Sep 2009 20:38:44 -0000 Received: from [192.168.2.4] (euler.heimnetz.de [192.168.2.4]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 274691721C for ; Sun, 13 Sep 2009 22:38:32 +0200 (CEST) Message-ID: <4AAD584F.1070601@apache.org> Date: Sun, 13 Sep 2009 22:38:39 +0200 From: Ruediger Pluem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090823 SeaMonkey/1.1.18 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: PR29744 References: <4AACDD53.4050004@apache.org> <4AACE35F.4020801@sharp.fm> <4AACEC29.7050003@apache.org> <4AAD2C4B.6050805@sharp.fm> In-Reply-To: <4AAD2C4B.6050805@sharp.fm> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 09/13/2009 07:30 PM, Graham Leggett wrote: > Ruediger Pluem wrote: > >>> The use of the connection in the HTTP proxy code is a prerequisite for >>> supporting SSL to a backend server. > >> As said there was no alternative as we had and have no SSL aware HTTP client library >> in httpd. > > We do, take a look for the "SSLProxy*" directives in mod_ssl. This SSL > support is possible because we use connections, not raw sockets. I guess we are circling around the same point with no real difference in opinion: All of the available HTTP code in httpd (as I said) and the SSL stuff (as you point out) was only available via that connection interface and no other more client oriented interface was present in httpd to use. So it was done with connections. And it works. 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. But this requires a complete rewrite of the current HTTP proxy code (like mod_serf does) and adds another library dependency on httpd. So the state is as is. But I stick to the point that I see no benefit in using the connection interface for handling the proxy connect interface, as the nature of the proxy connect interface is that we explicitly want a raw communication with the backend. Regards R�diger