Re: Adding AddHandler support for mod_proxy

2014-02-14 Thread ryo takatsuki
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 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.

 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.


APR_FOPEN_BUFFERED and small files

2014-02-14 Thread Christophe JAILLET

Hi,

when a file is opened using apr_file_open with the flag 
APR_FOPEN_BUFFERED, a 4096 bytes buffer is allocated in the pool.
4096 is the half of a pool block, so it often leads to the allocation 
of a new 8k block.


When opening .htaccess files, the APR_FOPEN_BUFFERED flag is set but in 
most cases, I think that this file is much smaller than 4096 bytes.
This lead to potentially allocating much more memory than useful in the 
request pool.



Do you think it would be interesting to teach apr_file_open to allocate 
max(size of the file, 4096) when opening small files with 
APR_FOPEN_BUFFERED set ?
I expect .htaccess file to be a few hundreds of byte. So this would save 
~ 3 ko in the request pool.


CJ



AW: APR_FOPEN_BUFFERED and small files

2014-02-14 Thread Plüm , Rüdiger , Vodafone Group


 -Ursprüngliche Nachricht-
 Von: Christophe JAILLET  Gesendet: Freitag, 14. Februar 2014 21:39
 An: dev@httpd.apache.org
 Betreff: APR_FOPEN_BUFFERED and small files
 
 Hi,
 
 when a file is opened using apr_file_open with the flag
 APR_FOPEN_BUFFERED, a 4096 bytes buffer is allocated in the pool.
 4096 is the half of a pool block, so it often leads to the allocation
 of a new 8k block.
 
 When opening .htaccess files, the APR_FOPEN_BUFFERED flag is set but in
 most cases, I think that this file is much smaller than 4096 bytes.
 This lead to potentially allocating much more memory than useful in the
 request pool.
 
 
 Do you think it would be interesting to teach apr_file_open to allocate
 max(size of the file, 4096) when opening small files with

You mean min(size of the file, 4096) ?

 APR_FOPEN_BUFFERED set ?
 I expect .htaccess file to be a few hundreds of byte. So this would save
 ~ 3 ko in the request pool.
 
 CJ


Regards

Rüdiger


Re: AW: APR_FOPEN_BUFFERED and small files

2014-02-14 Thread Marion Christophe JAILLET

lol, sure


Le 14/02/2014 21:44, Plüm, Rüdiger, Vodafone Group a écrit :



-Ursprüngliche Nachricht-
Von: Christophe JAILLET  Gesendet: Freitag, 14. Februar 2014 21:39
An: dev@httpd.apache.org
Betreff: APR_FOPEN_BUFFERED and small files

Hi,

when a file is opened using apr_file_open with the flag
APR_FOPEN_BUFFERED, a 4096 bytes buffer is allocated in the pool.
4096 is the half of a pool block, so it often leads to the allocation
of a new 8k block.

When opening .htaccess files, the APR_FOPEN_BUFFERED flag is set but in
most cases, I think that this file is much smaller than 4096 bytes.
This lead to potentially allocating much more memory than useful in the
request pool.


Do you think it would be interesting to teach apr_file_open to allocate
max(size of the file, 4096) when opening small files with

You mean min(size of the file, 4096) ?


APR_FOPEN_BUFFERED set ?
I expect .htaccess file to be a few hundreds of byte. So this would save
~ 3 ko in the request pool.

CJ


Regards

Rüdiger