You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bugs@httpd.apache.org by bu...@apache.org on 2009/02/16 17:59:34 UTC

DO NOT REPLY [Bug 38864] LocationMatch not working

https://issues.apache.org/bugzilla/show_bug.cgi?id=38864


Steve Madsen <st...@lightyearsoftware.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steve@lightyearsoftware.com
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #7 from Steve Madsen <st...@lightyearsoftware.com>  2009-02-16 08:59:32 PST ---
This bug is marked resolved and fixed, but it doesn't work in the current
2.2.11 release. ProxyPassReverse, in particular, still does not function inside
LocationMatch as an end-user expects it to after reading the 2.2 documentation.

I'm trying to account for case sensitivity on a proxied prefix, e.g.:

<LocationMatch ^(?i)/foo/>
    ProxyPassReverse http://foo.backend.server/
</LocationMatch>

Per http://www.apachetutor.org/admin/reverseproxies, ProxyPassReverse should be
set up like this to account for broken applications that issue a redirect using
only the path instead of a full URL.

Mainly I'm interested in clarification on this bug. Should it work? If so,
there is a regression in the current stable release.

If it is known not to work and there is no intention to fix it, I think the
documentation should be updated to explicitly state that the directives do not
work inside Location using the ~ syntax or in LocationMatch.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org