<div class="example"><h3>Single application instance</h3><pre class="prettyprint lang-config">ProxyPass /myapp/ fcgi://localhost:4000/</pre>
</div>
- <p>This application should be able to handle multiple concurrent
- connections. <code class="module"><a href="../mod/mod_proxy.html">mod_proxy</a></code> enables connection reuse by
- default, so after a request has been completed the connection will be
- held open by that httpd child process and won't be reused until that
- httpd process routes another request to the application. If the
- FastCGI application is unable to handle enough concurrent connections
- from httpd, requests can block waiting for the application to close
- an existing connection. One way to resolve this is to disable connection
- reuse on the <code class="directive">ProxyPass</code> directive, as shown in
- the following example:</p>
+ <p> <code class="module"><a href="../mod/mod_proxy_fcgi.html">mod_proxy_fcgi</a></code> disables connection reuse by
+ default, so after a request has been completed the connection will NOT be
+ held open by that httpd child process and won't be reused. If the
+ FastCGI application is able to handle concurrent connections
+ from httpd, you can opt-in to connection reuse as shown in the following
+ example:</p>
- <div class="example"><h3>Single application instance, no connection reuse</h3><pre class="prettyprint lang-config">ProxyPass /myapp/ fcgi://localhost:4000/ disablereuse=on</pre>
+ <div class="example"><h3>Single application instance, connection reuse (2.4.11 and later)</h3><pre class="prettyprint lang-config">ProxyPass /myapp/ fcgi://localhost:4000/ enablereuse=on</pre>
</div>
<p> The following example passes the request URI as a filesystem
path for the PHP-FPM daemon to run. The request URL is implicitly added
to the 2nd parameter. The hostname and port following fcgi:// are where
- PHP-FPM is listening.</p>
- <div class="example"><h3>PHP-FPM</h3><pre class="prettyprint lang-config">ProxyPassMatch ^/myapp/.*\.php(/.*)?$ fcgi://localhost:9000/var/www/</pre>
+ PHP-FPM is listening. Connection pooling is enabled.</p>
+ <div class="example"><h3>PHP-FPM</h3><pre class="prettyprint lang-config">ProxyPassMatch ^/myapp/.*\.php(/.*)?$ fcgi://localhost:9000/var/www/ enablereuse=on</pre>
</div>
<p> The following example passes the request URI as a filesystem
path for the PHP-FPM daemon to run. In this case, PHP-FPM is listening on
a unix domain socket (UDS). Requires 2.4.9 or later. With this syntax,
the hostname and optional port following fcgi:// are ignored.</p>
- <div class="example"><h3>PHP-FPM with UDS</h3><pre class="prettyprint lang-config">ProxyPassMatch ^/(.*\.php(/.*)?)$ "unix:/var/run/php5-fpm.sock|fcgi://localhost/var/www/"</pre>
+ <div class="example"><h3>PHP-FPM with UDS</h3><pre class="prettyprint lang-config"> # UDS does not currently support connection reuse
+ ProxyPassMatch ^/(.*\.php(/.*)?)$ "unix:/var/run/php5-fpm.sock|fcgi://localhost/var/www/"</pre>
</div>
<p>The balanced gateway needs <code class="module"><a href="../mod/mod_proxy_balancer.html">mod_proxy_balancer</a></code> and
reasons, you will want to define a <a href="mod_proxy.html#workers">worker</a>
representing the same fcgi:// backend. The benefit of this form is that it
allows the normal mapping of URI to filename to occur in the server, and the
- local filesystem result is passed to the backend.
+ local filesystem result is passed to the backend. When FastCGI is
+ configured this way, the server can calculate the most accurate
+ PATH_INFO.
</p>
<div class="example"><h3>Proxy via Handler</h3><pre class="prettyprint lang-config"><FilesMatch \.php$>
+ # Note: The only part that varies is /path/to/app.sock
SetHandler "proxy:unix:/path/to/app.sock|fcgi://localhost/"
+</FilesMatch>
+ # Define a matching worker.
+ # The part that is matched to the SetHandler is the part that
+ # follows the pipe. If you need to distinguish, "localhost; can
+ # be anything unique.
+ <Proxy fcgi://localhost/ enablereuse=on max=10>
+ </Proxy>
+
+<FilesMatch ...>
+ SetHandler "proxy:fcgi://localhost:9000"
+</FilesMatch>
+
+<FilesMatch ...>
+ SetHandler "proxy:balancer://myappcluster/"
</FilesMatch></pre>
</div>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
provider:</p>
<dl>
<dt>proxy-fcgi-pathinfo</dt>
- <dd>By default <code class="module"><a href="../mod/mod_proxy_fcgi.html">mod_proxy_fcgi</a></code> will neither create
- nor export the <var>PATH_INFO</var> environment variable. This allows
+ <dd>When configured via <code class="directive"><a href="../mod/mod_proxy.html#proxypass">ProxyPass</a></code> or <code class="directive"><a href="../mod/mod_proxy.html#proxypassmatch">ProxyPassMatch</a></code>, <code class="module"><a href="../mod/mod_proxy_fcgi.html">mod_proxy_fcgi</a></code> will not
+ set the <var>PATH_INFO</var> environment variable. This allows
the backend FCGI server to correctly determine <var>SCRIPT_NAME</var>
and <var>Script-URI</var> and be compliant with RFC 3875 section 3.3.
If instead you need <code class="module"><a href="../mod/mod_proxy_fcgi.html">mod_proxy_fcgi</a></code> to generate
a "best guess" for <var>PATH_INFO</var>, set this env-var.
- This is a workaround for a bug in some FCGI implementations.</dd>
+ This is a workaround for a bug in some FCGI implementations. This
+ variable can be set to multiple values to tweak at how the best guess
+ is chosen (In 2.4.11 and later only):
+ <dl>
+ <dt>first-dot</dt>
+ <dd>PATH_INFO is split from the slash following the
+ <em>first</em> "." in the URL.</dd>
+ <dt>last-dot</dt>
+ <dd>PATH_INFO is split from the slash following the
+ <em>last</em> "." in the URL.</dd>
+ <dt>full</dt>
+ <dd>PATH_INFO is calculated by an attempt to map the URL to the
+ local filesystem.</dd>
+ <dt>unescape</dt>
+ <dd>PATH_INFO is the path component of the URL, unescaped /
+ decoded.</dd>
+ <dt>any other value</dt>
+ <dd>PATH_INFO is the same as the path component of the URL.
+ Originally, this was the only proxy-fcgi-pathinfo option.</dd>
+ </dl>
+ </dd>
</dl>
</div>
</div>
projects / apache / commitdiff