2014-02-06 ryo takatsuki ryotakats...@gmail.com:
Hi,
I have an improvement request to suggest but I would like to first provide
some background to justify it, I apologise for the long email :).
I'm actively using mod_proxy to forward PHP files requests to PHP-FPM. My
current approach is to use a RewriteRule with the 'P' flag because (in most
of the cases) it plays nicely with other rules configured by the
applications I'm configuring, as well as allowing per-Directory
configurations.
To make it properly work I must assure the proxy RewriteRule must be the
latest one to be evaluated. The problem is that from time to time I
encounter corner cases in which the rules previously executed include a [L]
option that abort the next rules evaluation, skipping the proxy one, making
Apache serve the PHP text as plain text. This can be solved by tweaking the
rules but it is a tedious process and is hard to determine all the scenarios
in which the rewrites could go wrong.
IMHO this is a good idea, a handler is more compatible with .htacess
files created for
mod_php and it fits shared hosting env
Thinking about my goal with all of this was at the beginning, I realised I
only wanted a way of configuring a handler for all my PHP files, that in
this case is PHP-FPM, without having to worry about what happens before the
resource is going to be served. This made my think about the possibility of
adding this functionality to mod_proxy itself, allowing defining a proxy
worker as a handler for certain types of files. Something like:
AddHandler proxy:unix:/path/to/app.sock|fcgi://localhost/ .php
AddHandler might be tricky from security point of view, eg. most of cms software
usually checks only for last extension before writing uploaded files,
but this AddHandler will also
pass test.php.jpeg to php which might execute this
I made a quick POC, it is a really small change and for those in my
situation it could really simplify the configuration of their apps. Of
course, I'm open to criticisms and alternative solutions :).
The code that adds the new functionality is inserted at the beginning of
mod_proxy's proxy_handler. The conditions are a little weird because I only
wanted to check the handler if it is not a proxy request already.
diff --git a/modules/proxy/mod_proxy.c b/modules/proxy/mod_proxy.c
index 9d7c92f..49f3bdc 100644
--- a/modules/proxy/mod_proxy.c
+++ b/modules/proxy/mod_proxy.c
@@ -927,8 +927,20 @@ static int proxy_handler(request_rec *r)
struct dirconn_entry *list = (struct dirconn_entry
*)conf-dirconn-elts;
/* is this for us? */
-if (!r-proxyreq || !r-filename || strncmp(r-filename, proxy:, 6)
!= 0)
+if (!r-filename)
+ return DECLINED;
+
+if (!r-proxyreq) {
+ if (r-handler strncmp(r-handler, proxy:, 6) == 0
strncmp(r-filename, proxy:, 6) != 0) {
+r-proxyreq = PROXYREQ_REVERSE;
+r-filename = apr_pstrcat(r-pool, r-handler, r-filename, NULL);
+apr_table_setn(r-notes, rewrite-proxy, 1);
+ } else {
return DECLINED;
+ }
+} else if (strncmp(r-filename, proxy:, 6) != 0) {
+ return DECLINED;
+}
/* handle max-forwards / OPTIONS / TRACE */
if ((str = apr_table_get(r-headers_in, Max-Forwards))) {
