You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by ryo takatsuki <ry...@gmail.com> on 2014/02/06 16:03:00 UTC
Adding AddHandler support for mod_proxy
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.
Re: Adding AddHandler support for mod_proxy
Posted by ryo takatsuki <ry...@gmail.com>.
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 <ry...@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.
Re: Re: Adding AddHandler support for mod_proxy
Posted by ryo takatsuki <ry...@gmail.com>.
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 <pr...@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 <ji...@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 <ry...@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 <ry...@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 <la...@gmail.com>:
>>>>>>
>>>>>> 2014-02-06 ryo takatsuki <ry...@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.
Re: Re: Adding AddHandler support for mod_proxy
Posted by Andreas Bosch <pr...@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 <ji...@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 <ry...@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 <ry...@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 <la...@gmail.com>:
>>>>> 2014-02-06 ryo takatsuki <ry...@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.
>>>
>
>
Re: Adding AddHandler support for mod_proxy
Posted by Jim Jagielski <ji...@jaguNET.com>.
From what I can see, it's pretty useful and I'm not detecting
any errors or issues which would cause a regression. Final
testing will be done by COB today but I expect to fold it
into trunk, while adding some doc info.
On Feb 27, 2014, at 12:19 PM, ryo takatsuki <ry...@gmail.com> wrote:
>> 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!
>
> 2014-02-27 14:24 GMT+01:00 Jim Jagielski <ji...@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 <ry...@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 <ry...@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 <la...@gmail.com>:
>>>>> 2014-02-06 ryo takatsuki <ry...@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.
>
Re: Adding AddHandler support for mod_proxy
Posted by ryo takatsuki <ry...@gmail.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?
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!
2014-02-27 14:24 GMT+01:00 Jim Jagielski <ji...@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 <ry...@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 <ry...@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 <la...@gmail.com>:
>>>> 2014-02-06 ryo takatsuki <ry...@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.
Re: Adding AddHandler support for mod_proxy
Posted by Jim Jagielski <ji...@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 <ry...@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 <ry...@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 <la...@gmail.com>:
>>> 2014-02-06 ryo takatsuki <ry...@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.
>
Re: Adding AddHandler support for mod_proxy
Posted by ryo takatsuki <ry...@gmail.com>.
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 <ry...@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 <la...@gmail.com>:
>> 2014-02-06 ryo takatsuki <ry...@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.
Re: Adding AddHandler support for mod_proxy
Posted by ryo takatsuki <ry...@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 <la...@gmail.com>:
> 2014-02-06 ryo takatsuki <ry...@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.
Re: Adding AddHandler support for mod_proxy
Posted by Lazy <la...@gmail.com>.
2014-02-06 ryo takatsuki <ry...@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"))) {