Re: Need orientation around bucket brigades, subrequests, etc.
On Sat, Jul 20, 2013 at 6:41 AM, Vincenzo D'Amore v.dam...@gmail.com wrote: 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 Thanks, though unfortunately I'm fairly certain the only way to reliably support request bodies, as well as not call local requests twice, is to do some acrobatics with filters. I'd be grateful for any light you could shed on those issues. -- Dorian Taylor http://doriantaylor.com/
Re: Need orientation around bucket brigades, subrequests, etc.
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/
Need orientation around bucket brigades, subrequests, etc.
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/
