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>
<example><title>Proxy via Handler</title>
<highlight language="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>
</highlight>
</example>
provider:</p>
<dl>
<dt>proxy-fcgi-pathinfo</dt>
- <dd>By default <module>mod_proxy_fcgi</module> will neither create
- nor export the <var>PATH_INFO</var> environment variable. This allows
+ <dd>When configured via <directive module="mod_proxy"
+ >ProxyPass</directive> or <directive module="mod_proxy"
+ >ProxyPassMatch</directive>, <module>mod_proxy_fcgi</module> 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 <module>mod_proxy_fcgi</module> to generate