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