You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2013/12/09 20:02:33 UTC
ProxyPass in ... why not??
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
tia!
Re: ProxyPass in ... why not??
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On Mon, 9 Dec 2013 14:02:33 -0500
Jim Jagielski <ji...@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
Just one quick observation; on case insensitive file systems, we correct
/mixedcase/ (the directory name) to /docroot/MixedCase/ - how this would
then interact with the proxied user URL becomes an interesting question.
I would argue they don't interact because <files > and <directory >
should not be in the 'core of cores', but a separate loadable content
provider module. We know we aren't there right now (and have discussed
this before). But over a long history, people misused <Location > when
they desired directory-level acls, and this encourages <Directory > and
<Files > to be similarly confused. That said, I'm -0 on mixing these
concepts, but if you can invent a use case for <Directory > you can
just as easily invent a use case for <Files >.
Re: ProxyPass in ... why not??
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yeah, I'm not looking at the patch itself, just if the use
cases are correct and important enough to work the issue.
On Dec 12, 2013, at 7:29 AM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Dec 12, 2013 at 7:15 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> So I'm guessing that the use-cases described in
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=54616
>>
>> are bogus?
>>
>> I'm no pro nor con the change, just trying to understand
>> if such a change has merit.
>
> I think the use cases are legit, like per-directory RewriteRule with
> the P flag [to AF_UNIX workers]
>
> The patch in the PR seems to be something needed for an early AF_UNIX
> patch with rewrite escaping, but it does not at first blush look very
> safe.
>
Re: ProxyPass in ... why not??
Posted by Eric Covener <co...@gmail.com>.
On Thu, Dec 12, 2013 at 7:15 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> So I'm guessing that the use-cases described in
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=54616
>
> are bogus?
>
> I'm no pro nor con the change, just trying to understand
> if such a change has merit.
I think the use cases are legit, like per-directory RewriteRule with
the P flag [to AF_UNIX workers]
The patch in the PR seems to be something needed for an early AF_UNIX
patch with rewrite escaping, but it does not at first blush look very
safe.
Re: ProxyPass in ... why not??
Posted by Jim Jagielski <ji...@jaguNET.com>.
So I'm guessing that the use-cases described in
https://issues.apache.org/bugzilla/show_bug.cgi?id=54616
are bogus?
I'm no pro nor con the change, just trying to understand
if such a change has merit.
On Dec 12, 2013, at 5:18 AM, Nick Kew <ni...@webthing.com> wrote:
>
> On 11 Dec 2013, at 22:09, Eric Covener wrote:
>
>> My recollection was that it simply doesn't work (PR and quick test)
>
> Nor should it! There's enough userland confusion between
> URL-space and Filesystem-space. A change like r1031758
> that introduces a little more clarity should IMHO be welcomed!
>
> --
> Nick Kew
>
Re: ProxyPass in ... why not??
Posted by Nick Kew <ni...@webthing.com>.
On 11 Dec 2013, at 22:09, Eric Covener wrote:
> My recollection was that it simply doesn't work (PR and quick test)
Nor should it! There's enough userland confusion between
URL-space and Filesystem-space. A change like r1031758
that introduces a little more clarity should IMHO be welcomed!
--
Nick Kew
Re: ProxyPass in ... why not??
Posted by Eric Covener <co...@gmail.com>.
On Mon, Dec 9, 2013 at 2:02 PM, Jim Jagielski <ji...@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.