Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0D5EE10198 for ; Tue, 9 Jul 2013 15:48:09 +0000 (UTC) Received: (qmail 13736 invoked by uid 500); 9 Jul 2013 15:48:08 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 13603 invoked by uid 500); 9 Jul 2013 15:48:07 -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 13583 invoked by uid 99); 9 Jul 2013 15:48:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Jul 2013 15:48:07 +0000 X-ASF-Spam-Status: No, hits=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jorton@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Jul 2013 15:48:00 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r69FldX0020223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 9 Jul 2013 11:47:39 -0400 Received: from iberis.manyfish.co.uk (vpn-53-150.rdu2.redhat.com [10.10.53.150]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r69Flben016805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Jul 2013 11:47:38 -0400 Received: from jorton by iberis.manyfish.co.uk with local (Exim 4.80.1) (envelope-from ) id 1Uwa8f-0002Dz-F1 for dev@httpd.apache.org; Tue, 09 Jul 2013 16:47:37 +0100 Date: Tue, 9 Jul 2013 16:47:37 +0100 From: Joe Orton To: dev@httpd.apache.org Subject: Re: [PATCH] Fix "LDAPReferrals off" Message-ID: <20130709154737.GA8403@redhat.com> Mail-Followup-To: dev@httpd.apache.org References: <51C1773A.9070204@redhat.com> <51C2F684.90307@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Organization: Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Mark Hegarty (Ireland), Matt Parson (USA), Charlie Peters (USA) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Jun 20, 2013 at 08:41:04AM -0400, Eric Covener wrote: > I'm only concerned with someone who was getting by with LDAPReferrals > OFF because the default gave their SDK an error. Now OFF would be > fatal too. Just revisiting this... at least it seems clear that the docs do not match the code here, in that "LDAPRerrals off" does something surprising. So what are the choices? a) Jan's suggestion: offer a tri-state option on/off/default where "default" is equivalent to current "off". b) change the docs so that it is not implied that "LDAPReferrals off" really disables referral processing. c) ...something else? > But it's not so easy to do a separate "default" option because other > parts of the code need to know if referrals are being chased. I don't follow that: if the intent here is retaining the current behaviour of "LDAPReferrals off" for users who want that, then we can do that easily. Regards, Joe