Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of ryotakatsuki@gmail.com
 designates 209.85.192.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <531FA61F.70605@progandy.de>
References: 
 <CAKEW=8Q0mEFBWenQ_1n87G8OeS0pekSAk7HzxV+7QGzZVBOt4A@mail.gmail.com>
	<531FA61F.70605@progandy.de>
Date: Wed, 26 Mar 2014 17:09:20 +0100
Message-ID: 
 <CAKEW=8SVuuOEZ6qCmWRkrshS-QXNGXtpUc5xbxNrFtW80TAyvw@mail.gmail.com>
Subject: Re: Re: Adding AddHandler support for mod_proxy
From: ryo takatsuki <ryotakatsuki@gmail.com>
To: dev@httpd.apache.org, admin@progandy.de
Content-Type: text/plain; charset=ISO-8859-1

Hi,

That is the first approach we used (in fact, that was how we also
named it, mod_proxy_handler :)). The problem is that we support a lot
of different scenarios, sometimes we bundle our own apache, and
sometimes we use the native one from the system. In the former case,
we are ok with patching Apache or including a module (as we were
doing) but in the later, we have to rely on the system (including the
module ourselves would involve providing the module for a lot of
distributions) so the safest would be have it included in Apache
default set of modules already, so we can assume, for example, default
2.4.10+ will work  if mod_proxy is there (which is mandatory anyways
for this functionality).

 As we thought the change would be really useful to the community (we
tested multiple configurations to support PHP-FPM and this was the
best one) and really small, we suggested the patch to be merged in
mod_proxy.

We also thought it was better to submit it as an patch for mod_proxy
instead of submitting it as an additional module because it was really
simple and safe, and is tightly related to mod_proxy.


2014-03-12 1:11 GMT+01:00 Andreas Bosch <progandy@progandy.de>:
> Am 27.02.2014 18:19, schrieb ryo takatsuki:
>
>>> 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?
>>
>> If there is, we could not find it :) We have been searching for months
>> and trying different approaches. This is required to work with out of
>> the box installation of many apps without requiring them to modify
>> their htaccess files.
>>
>> Thanks for looking into it!
>>
>
> Hi,
> You can put the patch in its own module, it is not required to be part of
> mod_proxy if you can accept to use internals of one module in another. That
> is what I am currently doing with apache 2.4 since I like to use the binary
> package of my distribution without the need to recompile the whole server.
>
> https://gist.github.com/progandy/6ed4eeea60f6277c3e39/
>
>
>> 2014-02-27 14:24 GMT+01:00 Jim Jagielski <jim@jagunet.com>:
>>>
>>> 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.
>>>>
>>
>>
>
>


-- 
 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.