httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ryo takatsuki <ryotakats...@gmail.com>
Subject Re: Adding AddHandler support for mod_proxy
Date Fri, 14 Feb 2014 18:11:08 GMT
Hi all,

Does anybody has any feedback on the patch ?  Any concerns or suggestions?

Thanks!


2014-02-06 16:03 GMT+01:00 ryo takatsuki <ryotakatsuki@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.
>
> 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
>
>
> 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"))) {
>
> Best regards,
>
> Juanjo.
>
>
>


-- 
 I've seen things you people wouldn't believe.
Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the dark near Tannhauser Gate.
All those moments will be lost in time like tears in rain.
Time to die.

Mime
View raw message