In our case, it is usually enough to use mod_proxy with simply a
ProxxPass and ProxyPassReverse directive, forwarding complete
"directories" to the back end.
That means we forward all requests to the applications, which reside
in another machine in the backend, as they also include styles,
images... One could configure some requests to be served directly by
Apache, but that would mean we would have to split the applications in
two pieces, one to reside in the Apache host, the dynamic one to
reside in the application server... and that is something we don't
want, due to the number of applications we have to mantain.
In any case, in those specific cases where we needed to proxy specific
types of requests, we would then use mod_rewrite and then mod_proxy,
as the version of Apache we use, for other unrelated reasons, still
does not have ProxyPassMatch.
So, even if ProxyPassMatch is broken, you could still go back to the
good ol' mod_rewrite/mod_proxy combo for those specific needs.
S'està citant david day <yaya...@gmail.com>:
> This is a smashing idea, and I feel like an idiot for not seeing it.
> Unfortunately, ProxyPassMatch is broken in the RPM based RedHat
> Apache. This is at the same time mod_caucho will not build on any new
> CentOS or RedHat servers.
> Is your use of mod_proxy fairly basic, or have you been required to do
> some imaginative directives with regex? At least with mod_proxy, I
> can upgrade Apache and utilize ProxyPassMatch where mod_caucho fails
> under any configuration. I'm not excited about this prospect either,
> but there is nothing we can do about mod_caucho. You have given me
> another option out of this problem.
> resin-interest mailing list
resin-interest mailing list