Hi, I have implemented just same thing using rewritemap and a little of PHP. If you are interested to evaluate a different approach take a look at this:
http://stackoverflow.com/questions/13030557/apache-just-rewrite-if-external-ressource-exists/16647345#16647345 Regards, Vincenzo -- Vincenzo D'Amore On 19/lug/2013, at 21:05, dorian taylor <dorian.taylor.li...@gmail.com> wrote: > Hello, > > I am currently prototyping a module that does the equivalent of this > mod_rewrite incantation: > > RewriteCond %{REQUEST_URI} !-U > RewriteRule (.*) http://another.host$1 [P,NS] > > ...in other words, "if a resource cannot be found on the local server, > reverse-proxy the request to another.host." This incantation, of > course, won't work as expected, because mod_rewrite evaluates > RewriteCond *after* RewriteRule, hence the need for a custom module. > Moreover, whichever response handler is installed for the URI, even > core, typically has to be run in order to discover whether or not it > returns a 404, so even if that incantation *did* work properly, it > still wouldn't produce the desired effect. > > What this means is that the requested resource has to be run > end-to-end in a subrequest, and, in the event of a 404, its output > discarded before the request is handed off to the proxy. > > That's all fine. I can do all that. However: a) dealing with request > bodies and b) handling interactions with other parts of the system > (specifically filters), opens up quite the can of worms. > > Running the subrequest locally will consume the input brigade. I'm > counteracting that by installing a filter that tucks the input into a > temporary file, and then another filter which replays the input back > into the proxy request, if there is any of either. (Aside: it is worth > noting that the proxy request itself must not be a subrequest, as > mod_proxy_http discards subrequest bodies.) > > If, however, the subrequest response is successful, I need to be able > to hang on to the response content and somehow promote it into main > request, so the configured filters will run against it (I have filters > that won't run except for main requests). > > What I don't know a lot about is how the I/O brigade system *itself* > works. Am I right in understanding there's only one pair per > connection? > > I should also mention this prototype is in mod_perl, which is more or > less irrelevant to the problem, except for the fact that > modperl_response_handler's priority is APR_HOOK_MIDDLE whereas > proxy_handler is APR_HOOK_FIRST. About all that means is the main > logic can't manifest as a response handler because by then the proxy > handler will already have been run. (It's also undesirable to run this > logic in a response handler because that will get in the way of any > other response handler that's been configured.) > > A background writeup on why I want this thing to exist is here: > http://doriantaylor.com/the-redesign-dissolved > The code is here: > https://github.com/doriantaylor/p5-apache2-condproxy/blob/master/lib/Apache2/CondProxy.pm > > I'd be grateful if anybody could either explain or point me in the > direction of a definitive summary of how request phases, subrequests > and the bucket brigades interact. > > Thanks, > > -- > Dorian Taylor > http://doriantaylor.com/
