Return-Path: 
 <dev-return-79360-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org>
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 7618C10A3C
	for <apmail-httpd-dev-archive@www.apache.org>;
 Wed, 11 Dec 2013 22:09:29 +0000 (UTC)
Received: (qmail 19751 invoked by uid 500); 11 Dec 2013 22:09:28 -0000
Delivered-To: apmail-httpd-dev-archive@httpd.apache.org
Received: (qmail 19703 invoked by uid 500); 11 Dec 2013 22:09:28 -0000
Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
list-help: <mailto:dev-help@httpd.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@httpd.apache.org>
List-Post: <mailto:dev@httpd.apache.org>
List-Id: <dev.httpd.apache.org>
Delivered-To: mailing list dev@httpd.apache.org
Received: (qmail 19695 invoked by uid 99); 11 Dec 2013 22:09:28 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Dec 2013 22:09:28 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of covener@gmail.com designates
 209.85.128.177 as permitted sender)
Received: from [209.85.128.177] (HELO mail-ve0-f177.google.com)
 (209.85.128.177)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Dec 2013 22:09:22 +0000
Received: by mail-ve0-f177.google.com with SMTP id db12so6387760veb.22
        for <dev@httpd.apache.org>; Wed, 11 Dec 2013 14:09:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=axEFUCMDOkjRurFtPxeZ7O4J43ghC9M6R7XK3lFRSLg=;
        b=rJbogltRBBrHiuYWkrM5v9jUSjlAyHn1jUQ4ubgvDxqopnduq+X+OYi1ZbEWrKdmlr
         Jni3LteBWHsAgx2jyn106D0NqyI9+y4Fq4l33s+rttodP1d5sPcbbuB1vcMYdFxyBUR1
         gbpJUjzv0iHcTgwaFC8xkqrTjxK/kQOCkYsuP/yAvq8kT1EJIbMB4KV7VffW5a3c150p
         ioVixPRyCK8u75jbJD86+u9G1qE5epzTh2q5m6Y293QfB3f1HlshgZe39+0vbEMCBsL7
         AcWiPAwOOdYheVp/0dt8B4dydokatUn1S/MByENzpDlRdPUFNhhm9wfDh8zU7lYqymDd
         eh9Q==
MIME-Version: 1.0
X-Received: by 10.52.191.98 with SMTP id gx2mr797439vdc.71.1386799741859; Wed,
 11 Dec 2013 14:09:01 -0800 (PST)
Received: by 10.58.85.9 with HTTP; Wed, 11 Dec 2013 14:09:01 -0800 (PST)
In-Reply-To: <A11D8A9A-4AE7-4BF3-A10C-1219AC806B7C@jaguNET.com>
References: <A11D8A9A-4AE7-4BF3-A10C-1219AC806B7C@jaguNET.com>
Date: Wed, 11 Dec 2013 17:09:01 -0500
Message-ID: 
 <CALK=YjNTnkpcFZpPKO+H145ZnT8Vf0McveWDWghhvFCVu6EcNg@mail.gmail.com>
Subject: Re: ProxyPass in <directory>... why not??
From: Eric Covener <covener@gmail.com>
To: Apache HTTP Server Development List <dev@httpd.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org

On Mon, Dec 9, 2013 at 2:02 PM, Jim Jagielski <jim@jagunet.com> wrote:
> We know that ProxyPass works in <Location>, since it was
> added in http://svn.apache.org/viewvc?view=revision&revision=1026184.
>
> However, the very next patch (http://svn.apache.org/viewvc?view=revision&revision=1031758)
> prevents it from working in <Directory> (as well as <Files>, but I'm
> ignoring that)...
>
> My question is why? From what I can see, the only reason
> is to close https://issues.apache.org/bugzilla/show_bug.cgi?id=47765
> but I again wonder why we allow Location but not Directory?

> Anyone have any further info on why? And yes, this is related
> to https://issues.apache.org/bugzilla/show_bug.cgi?id=54965

My recollection was that it simply doesn't work (PR and quick test)
So I tried to split it into a "don't silently fail to proxy" PR and a
"please support this" PR.

Proxy stakes its claim to a request in translate_name, which is after
the location walk but before the directory/file walk. So it makes
sense that is sees no configuration there given the current impl of
storing the per-directory ProxyPass in actual per-directory config.

The fix would need to include (I think?) some way of normalizing or
ignoring cmd->path, which is used instead of the first parm but
doesn't make much sense in terms of <Directory>.

But I am not so invested in any of it, so if something works for you
in sandbox no qualms here with changes.