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"))) {
