Summary: | Socket backend support for mod_proxy | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Francesco <framelio> |
Component: | mod_proxy | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | admin, apache, apache_bugzilla, blaise.tarr, diemuzi, erik, glicerinu, m.hofer117, pothi, tobias.pal, tomas, ubunciak |
Priority: | P2 | Keywords: | FixedInTrunk, PatchAvailable |
Version: | 2.4.3 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Attachments: |
Patch for socket support on mod_proxy
Unix domain socket support for mod_proxy (patch) Patch for 2.4.x (or 2.4.7) |
Description
Francesco
2012-11-05 16:10:23 UTC
Created attachment 29995 [details] Unix domain socket support for mod_proxy (patch) I updated my patch to resolve a problem on BSD systems. This patch was generated against Apache 2.4.4. Below is my original announcement on the Apache dev mailing list: The attached patch adds support for Unix domain sockets (UDS) to mod_proxy. This is very beneficial when configuring a reverse proxy using mod_proxy_fcgi to connect to PHP-FPM. In some tests with ab there was over 20% improvement in the request rate when using a UDS instead of TCP. Since remote servers in mod_proxy are configured with a URL, I took the idea from this page on how to represent a UDS as a URL: http://daniel.haxx.se/blog/2008/04/14/http-over-unix-domain-sockets/ So the host portion of the URL contains "socket=" followed by the URI encoded socket path (upper case characters must be encoded too). Below are a couple of examples where PHP-FPM's socket is /tmp/php-fpm.sock and the document root is /local/htdocs: ProxyPass fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/ RewriteRule (.*\.php) fcgi://socket=\%2ftmp\%2fphp-fpm.sock/local/htdocs/$1 [P,L] The following are not contained in the patch: * bump MMN due to mod_proxy.h changes * assign APLOGNO numbers * detection of AF_UNIX support in configure Thanks for your consideration, Blaise Not had a chance to review the patch, but a definite +1 in principle. +1 for stable implementation in the next http 2.4.x releases Will fold into trunk for testing and enhancement. Thx Would it be possible to fix it to support RewriteRule in <Directory></Directory> block (now RewriteRule only works if not in Directory section, if it is placed in Directory block, then it does not replace %2f to / well (leaves f instead of /)). Now there is no any other way to use it in Directory block, because ProxyPassMatch does not work there too (https://issues.apache.org/bugzilla/show_bug.cgi?id=54616). There's one problem haven't solved by this patch. The function proxy_fcgi_canon in mod_proxy_fcgi.c will modify proxy url. fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/ this url will become fcgi://socket=%2ftmp%2fphp-fpm.sock:8000/local/htdocs/ So, it's important to use nocanon in ProxyPass. If you choose ProxyPassMatch, then your proxy url will always be changed. +1 for stable implementation, waiting for this so long. It's critical to use with php-fpm Please check https://issues.apache.org/bugzilla/show_bug.cgi?id=54616#c7. It is related to this bug. I see the patch already included in trunk but the part in which the PROXY_WORKER_MAX_HOSTNAME_SIZE and PROXY_WORKER_MAX_NAME_SIZE were increased is not there (I realized that after get a "ProxyPass worker name (fcgi://uds=%2fsome%2fsocket.sock/tmp/somedirectory too long)"). Was that dropped intentionally? This will allow Phusion Passenger Standalone to be reverse proxied by Apache as a unix domain socket! Right now Apache can only reverse proxy over TCP, but Nginx can reverse proxy to a socket, making it the better performer for Ruby apps using this setup, and making me jealous, since I have an all Apache infrastructure. Any chance of backporting this to 2.2 stable? I second this, 64 bytes is not sufficiently long. It is prohibitively short when, for example, using Amazon AWS long hostnames for back end systems Have I missed a reason why it needs to be so short? According to wikipedia (and I fully appreciate this is very unprofessional to quote WP) http://en.wikipedia.org/wiki/Hostname Each label must be between 1 and 63 characters long,[2] and the entire hostname (including the delimiting dots) has a maximum of 255 characters Can we assume that the backend can be FQDN not just a single host? 255 characters would seem a minimum for a FQDN. 64 is only sufficient for a single hostname. (In reply to ryotakatsuki from comment #9) > I see the patch already included in trunk but the part in which the > PROXY_WORKER_MAX_HOSTNAME_SIZE and PROXY_WORKER_MAX_NAME_SIZE were increased > is not there (I realized that after get a "ProxyPass worker name > (fcgi://uds=%2fsome%2fsocket.sock/tmp/somedirectory too long)"). Was that > dropped intentionally? +1 for adding this or similar capability to support PHP-FPM. Does the patch work on latest 2.4.7 release? It hasn't been included, but I can always manually patch it if there are no dependencies. (In reply to me from comment #13) > Does the patch work on latest 2.4.7 release? > It hasn't been included, but I can always manually patch it if there are no > dependencies. Appears the patch does not work with 2.4.7 patching file mod_proxy.h Hunk #1 succeeded at 236 (offset 4 lines). Hunk #2 succeeded at 308 (offset 4 lines). patching file proxy_util.c Hunk #2 succeeded at 2028 (offset 7 lines). Hunk #3 succeeded at 2045 (offset 7 lines). Hunk #4 FAILED at 2156. Hunk #5 succeeded at 2403 (offset 19 lines). Hunk #6 succeeded at 2471 (offset 19 lines). Hunk #7 succeeded at 2607 (offset 19 lines). 1 out of 7 hunks FAILED -- saving rejects to file proxy_util.c.rej Damn, guess I need to use mod FastCGI till the next major version release. Thankfully someone was kind enough to release a 2.4 compatible version https://github.com/ByteInternet/libapache-mod-fastcgi Hope this will be fixed in some future minor release of 2.4.x Very crucial for my production env to switch on apache 2.4, but I'm using PHP-FPM with unix-sockets and definitely won't go with TCP sockets. Before that's done will stay on apache 2.2 and/or nginx. Its a pity we had a patch, it was not implemented into development and now it doesn't work anymore. Stuck in 2.2.. And trying nginx. (In reply to Jose from comment #17) > Its a pity we had a patch, it was not implemented into development and now > it doesn't work anymore. > > Stuck in 2.2.. And trying nginx. This support has been in trunk/2.5 since early last year. The patch being considered for backport to 2.4.x is heree: http://people.apache.org/~jim/patches/uds-2.4.patch The latest status on it is here: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x/STATUS Of course, as it ages, there may be cosmetic breakage of the diff. Any feedback is welcome. Created attachment 31232 [details] Patch for 2.4.x (or 2.4.7) This patch is the same as http://people.apache.org/~jim/patches/uds-2.4.patch (modulo CHANGES/manual/ap_mmn.h) working with current 2.4.x (and 2.4.7). It seems that this patch has landed in 2.4.8/2.4.9. But I'm not sure how to use it with ProxyPassMatch I've tried the example above (fcgi://socket=%2ftmp%2fphp-fpm.sock/local/htdocs/ ) but that didn't work. I did a test and the correct syntax for ProxyPassMatch is ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/path/to/socket.sock|fcgi://localhost/path/to/docroot/ The host localhost doesn't really matter, you can put whatever. (In reply to Francesco from comment #21) > I did a test and the correct syntax for ProxyPassMatch is > > ProxyPassMatch ^/(.*\.php(/.*)?)$ > unix:/path/to/socket.sock|fcgi://localhost/path/to/docroot/ > > The host localhost doesn't really matter, you can put whatever. That works now. Although if I put $1 (as described at http://wiki.apache.org/httpd/PHP-FPM), it fails with a 503. in 2.4.7 The proper syntax in my case Apache/2.4.6 (Linux/SUSE) is unix:///var/run/php-fpm.sock|fcgi://127.0.0.1:9000/srv/www/$1 With a triple slash, otherwise apache complain of ProxyPass URL must be absolute! |