Proxy and rewrite ordering
In mod_rewrite.c, I see
ap_hook_translate_name(hook_uri2file, NULL, NULL, APR_HOOK_FIRST);
In mod_proxy.c, I see
/* fixup before mod_rewrite, so that the proxied url will not
* escaped accidentally by our fixup.
*/
static const char * const aszSucc[]={ mod_rewrite.c, NULL };
ap_hook_translate_name(proxy_trans, aszSucc, NULL, APR_HOOK_FIRST);
Now, mod_rewrite's hook_uri2file sets r-proxyreq = PROXYREQ_REVERSE
if it activates a [P], and mod_proxy's proxy_trans
What exactly is the risk that's protecting against? I'd like to run the
mod_rewrite hook before the mod_proxy one, to have the mod_rewrite
environment variables available in proxy_trans.
It looks to me as if the only thing that'll affect that ordering is
mod_proxy's
if (r-proxyreq) {
/* someone has already set up the proxy, it was possibly ourselves
* in proxy_detect
*/
return OK;
}
So, presumably it should work if I run two proxy_trans hooks: the
first just makes the above check and returns DECLINED if not;
the second makes the same check but follows it with the
ProxyPass stuff.
Or am I missing something deeper?
--
Nick Kew
Corrected: Proxy and rewrite ordering
[my previous post contained some irrelevant observations I
thought I'd deleted. Reposting to reduce confusion]
In mod_rewrite.c, I see
ap_hook_translate_name(hook_uri2file, NULL, NULL, APR_HOOK_FIRST);
In mod_proxy.c, I see
/* fixup before mod_rewrite, so that the proxied url will not
* escaped accidentally by our fixup.
*/
static const char * const aszSucc[]={ mod_rewrite.c, NULL };
ap_hook_translate_name(proxy_trans, aszSucc, NULL, APR_HOOK_FIRST);
What exactly is the risk that's protecting against? I'd like to run the
mod_rewrite hook before the mod_proxy one, to have the mod_rewrite
environment variables available in proxy_trans.
It looks to me as if the only thing that'll affect that ordering is
mod_proxy's
if (r-proxyreq) {
/* someone has already set up the proxy, it was possibly ourselves
* in proxy_detect
*/
return OK;
}
So, presumably it should work if I run two proxy_trans hooks: the
first just makes the above check and returns DECLINED if not;
the second makes the same check but follows it with the
ProxyPass stuff.
Or am I missing something deeper?
--
Nick Kew
conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
(ignore issues of support for particular versions of Apache) google pretends to know a lot about this general question, but it seems to be in discussions between general users with the same curiosity and there is little or no developer input. OTOH, there is a great indication that Tomcat connector FAQ and httpd documentation could help a lot of people by presenting the same conclusion, whatever that happens to be ;) Are there key design issues which will make one better than the other assuming each has enough developer attention to fix code bugs? Are there still fundamental pieces missing from mod_proxy_ajp + mod_proxy_balancer which have to be resolved before mod_proxy_ajp is the natural solution for anybody on Apache = 2.2? When should somebody use mod_proxy_http [+ mod_proxy_balancer] instead of one of these solutions? The Tomcat connectors FAQ says this: ---snip # mod_jk is great and should be used for production. It is getting fixes as needed (which is now rare). # mod_proxy. A cheap way to proxy without the hassles of configuring JK. This solution lacks sticky session load balancing. If you don't need some of the features of jk, jk2 - this is a very simple alternative. # mod_proxy_ajp. With apache 2.2, mod_proxy was rewritten to support load balancing as well as a new transport called mod_proxy_ajp. This module is distributed with the Apache http server, not the Tomcat server. ---snip--- Isn't pass-through of client SSL connection information another problem with mod_proxy? (servlets can't access cipher or client certificate)
Re: Corrected: Proxy and rewrite ordering
On 05/27/2006 02:47 PM, Nick Kew wrote:
[my previous post contained some irrelevant observations I
thought I'd deleted. Reposting to reduce confusion]
In mod_rewrite.c, I see
ap_hook_translate_name(hook_uri2file, NULL, NULL, APR_HOOK_FIRST);
In mod_proxy.c, I see
/* fixup before mod_rewrite, so that the proxied url will not
* escaped accidentally by our fixup.
*/
static const char * const aszSucc[]={ mod_rewrite.c, NULL };
ap_hook_translate_name(proxy_trans, aszSucc, NULL, APR_HOOK_FIRST);
Sorry for being confused, but as far as I read the line above mod_rewrite runs
*before* mod_proxy in the translate_name hook. It actually runs *after*
mod_rewrite
in the fixup hook:
ap_hook_fixups(proxy_fixup, NULL, aszSucc, APR_HOOK_FIRST);
And that is what the comment before
/* fixup before mod_rewrite, so that the proxied url will not
* escaped accidentally by our fixup.
*/
static const char * const aszSucc[]={ mod_rewrite.c, NULL };
is about. I admit that this also confused myself.
Regards
Rüdiger
Re: conclusions to FAQs on mod_proxy_ajp vs. mod_jk?
On 05/27/2006 03:58 PM, Jeff Trawick wrote: Are there still fundamental pieces missing from mod_proxy_ajp + mod_proxy_balancer which have to be resolved before mod_proxy_ajp is the natural solution for anybody on Apache = 2.2? Currently mod_proxy_balancer lacks the domain feature of mod_jk, but I do not know if this is regarded as fundamental piece. Isn't pass-through of client SSL connection information another problem with mod_proxy? (servlets can't access cipher or client certificate) AFAIK not with mod_proxy_ajp. It seems to pass all these information to Tomcat. Regards Rüdiger
Re: Corrected: Proxy and rewrite ordering
On Saturday 27 May 2006 19:40, Ruediger Pluem wrote: Sorry for being confused, but as far as I read the line above mod_rewrite runs *before* mod_proxy in the translate_name hook. It actually runs *after* mod_rewrite in the fixup hook: Bah. [mutter]. Harumph! Oh well, nevermind. Serves me right for taking the name and comment at face value. Thanks for untangling my poor little braincell. -- Nick Kew
Re: [PATCH] properly set the parent pid on shutdown
Davi Arnaut wrote: On Fri, 26 May 2006 13:48:05 -0500 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: +1 on visual review. Anyone have a win9x install handy to verify that this works? Sorry, none of my multiboots still boot 9x. I've personally tested it on WIN98 (virtual machine). Just a heads up... during development I saw varying behavior on 95, 98, 98SE and ME. shrug/ I would appreciate if more that one person could test this before we commit to 2.0 or 2.2 branch. Perhaps I should create a binary from the patch + 2.0.58/2.2.2 and let folks download that to verify based on a plea to [EMAIL PROTECTED] Bill
[PATCH] No temporary file left behind
Hi,
Remove mod_disk_cache temporary files when rename() fails, otherwise
they may accumulate in excess.
--
Davi Arnaut
Index: modules/cache/mod_disk_cache.c
===
--- modules/cache/mod_disk_cache.c (revision 409900)
+++ modules/cache/mod_disk_cache.c (working copy)
@@ -165,7 +165,10 @@
*/
rv = apr_file_rename(dobj-tempfile, dobj-datafile, r-pool);
if (rv != APR_SUCCESS) {
-/* XXX log */
+ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, r-server,
+ disk_cache: rename tempfile to datafile failed: %s
- %s,
+ dobj-tempfile, dobj-datafile);
+apr_file_remove(dobj-tempfile, r-pool);
}
dobj-tfd = NULL;
@@ -854,6 +857,7 @@
ap_log_error(APLOG_MARK, APLOG_DEBUG, rv, r-server,
disk_cache: rename tempfile to varyfile failed: %s - %s,
dobj-tempfile, dobj-hdrsfile);
+apr_file_remove(dobj-tempfile, r-pool);
return rv;
}
@@ -946,6 +950,7 @@
ap_log_error(APLOG_MARK, APLOG_ERR, rv, r-server,
disk_cache: rename tempfile to hdrsfile failed: %s -
%s,
dobj-tempfile, dobj-hdrsfile);
+apr_file_remove(dobj-tempfile, r-pool);
return rv;
}
