httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Adding AddHandler support for mod_proxy
Date Thu, 27 Feb 2014 13:24:25 GMT
Thx for the patch! Let me take a look... I'm assuming that there's
no real work-around other than the patch itself, right?

On Feb 26, 2014, at 1:47 PM, ryo takatsuki <ryotakatsuki@gmail.com> wrote:

> Hi all,
> 
> Any other comments about the patch? I believe it is simple enough and
> could ease the migration from mod_php to PHP-FPM (and make use of the
> new event mode) with minimal changes to the default configurations.
> Could you consider adding it? Pretty please :)
> 
> To give more background, at Bitnami we have 800.000+ monthly *new*
> installs just for Apache + PHP environments, a growing number of them
> in the cloud. We have daily requests for switching to nginx as the
> default, but we believe Apache 2.4 event MPM + PHP-FPM to be
> equivalent in terms of performance and you get all the other goodness
> of Apache. This is a small change that would make the transition to
> the event MPM on our side significantly easier (long story)
> 
> Best regards,
> 
> Juanjo.
> 
> 2014-02-18 15:46 GMT+01:00 ryo takatsuki <ryotakatsuki@gmail.com>:
>>> 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
>> 
>> Yes, It would be probably safer to use something like:
>> 
>> <FilesMatch \.php$>
>>    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
>> </FilesMatch>
>> 
>> 2014-02-17 0:11 GMT+01:00 Lazy <lazy404@gmail.com>:
>>> 2014-02-06 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.
>>> 
>>> 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"))) {
>> 
>> 
>> 
>> --
>> 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.
> 
> 
> 
> -- 
> 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