From dev-return-57547-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Thu Jun 21 08:27:52 2007 Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 28485 invoked from network); 21 Jun 2007 08:27:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Jun 2007 08:27:50 -0000 Received: (qmail 48426 invoked by uid 500); 21 Jun 2007 08:27:47 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 48362 invoked by uid 500); 21 Jun 2007 08:27:47 -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 48351 invoked by uid 99); 21 Jun 2007 08:27:47 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jun 2007 01:27:47 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [195.233.129.143] (HELO rat01038.dc-ratingen.de) (195.233.129.143) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jun 2007 01:27:42 -0700 Received: from rat01047.dc-ratingen.de (rat01047_e0 [195.233.128.119]) by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id l5L8RIsr029913 for ; Thu, 21 Jun 2007 10:27:18 +0200 (MEST) Received: from avoexs02.internal.vodafone.com ([145.230.4.135]) by rat01047.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id l5L8RJUo006988 for ; Thu, 21 Jun 2007 10:27:19 +0200 (MEST) Received: from EITO-MBX03.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 10:27:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: ProxyTimeout does not work as documented Date: Thu, 21 Jun 2007 10:27:18 +0200 Message-ID: <3B21A253728EA247A10A692547A271538DCBC1@EITO-MBX03.internal.vodafone.com> In-Reply-To: <1182412531.3756.2.camel@jfcpc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ProxyTimeout does not work as documented Thread-Index: Acez2XBswI3WbZ8NT7m5g4/nTAPw9QAA7lNA From: =?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VF-Group?= To: X-OriginalArrivalTime: 21 Jun 2007 08:27:20.0780 (UTC) FILETIME=[FC71A8C0:01C7B3DD] X-Virus-Checked: Checked by ClamAV on apache.org > -----Urspr=FCngliche Nachricht----- > Von: Jean-Frederic=20 > Gesendet: Donnerstag, 21. Juni 2007 09:56 > An: dev@httpd.apache.org > Betreff: Re: ProxyTimeout does not work as documented >=20 >=20 > On Mon, 2007-06-18 at 13:57 +0200, Pl=FCm, R=FCdiger, VF-Group wrote: > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Jean-Frederic =20 > > > Gesendet: Montag, 18. Juni 2007 12:06 > > > An: dev@httpd.apache.org > > > Betreff: Re: ProxyTimeout does not work as documented > > >=20 > > >=20 > > > On Sat, 2007-06-16 at 17:40 +0200, Ruediger Pluem wrote: > > > >=20 > > > >=20 > > > > Digging somewhat deeper to actually do this I found the=20 > following > > > > obstacle (hopefully I am wrong): > > > >=20 > > > > 1. The right place to fix this is in ap_proxy_connect_backend > > > > (around line 2215 in proxy_util.c). > > >=20 > > > The Timeout is the Default value already See =20 > > > c->base_server->timeout in > > > core_pre_connection().=20 > >=20 > > This happens afterwards in ap_proxy_connection_create and=20 > not for mod_proxy_ajp as > > mod_proxy_ajp does not call ap_proxy_connection_create.=20 > This was fixed by > > your patch in r546128. > >=20 > > >=20 > > > >=20 > > > > 2. We do not have a proxy_server_conf parameter in=20 > > > ap_proxy_connect_backend > > > > like in ap_proxy_connect_to_backend. > > > >=20 > > > > 3. ap_proxy_connect_backend is part of a public API=20 > (mod_proxy.h). > > > >=20 > > > > 4. Fixing the prototype of ap_proxy_connect_backend to add=20 > > > a proxy_server_conf > > > > parameter thus requires a major bump. Thus this would=20 > > > not be backportable :-(. > > > >=20 > > > > I am not quite sure if we can do > > > >=20 > > > > void *sconf =3D s->module_config; > > > > proxy_server_conf *conf =3D (proxy_server_conf *) > > > > ap_get_module_config(sconf, &proxy_module); > > >=20 > > > See modules/proxy/mod_proxy_balancer.c > >=20 > > Thanks for the pointer, but I stick to my opinion that this is ugly > > there. But possibly we can go for the ugly way in 2.2.x and for the > > API change in trunk. > >=20 >=20 > The "ugly" hack works. Should I apply the attached patch? As said for trunk I would prefer the "cleaner" way by changing the API (including the needed major bump). I think the patch is a good solution as a backport for solving the issue in 2.2.x. I hoped to get more = feedback on this approach, but it seems that currently only you and I are working on this. So once we agree on the solution we should move forward. Lazy = consensus :-). So opinions on the above? Regards R=FCdiger