httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From PanaColina <>
Subject Re: [users@httpd] DirectoryIndex fails to serve file to proxy (php-fpm, proxy_fcgi_module)
Date Wed, 19 Sep 2012 05:43:48 GMT
Thank you for your indulgent response to my so ignorant request.

I will move this to a relevant PHP list (although I tried more than a week
ago on a PHP-FPM list, with no response).

I did understand that *this is not an error in Apache HTTP Server*, but
Apache has had workarounds for some issues with proxies and other external

I did not know exactly how directory indexing worked. I am now educated --
thank you.

As for your RewriteRule for directories, I tried it, and while it did work
for /, it did not work for /sub/subdirectories, although I thought it
should. I will try testing again later.

As for your patch, I have had luck a couple of times simply declaring
something, but as I said: *I am not a progammer*. As I was using your patch
against the exact same version of PHP as your patch was named for
(php-5.4.6), I was surprised by the required offset (as previously noted).
And yes, I have built PHP-FPM successfully, on three different servers
(with php-5.4.6 and php-5.4.7, with httpd-2.4.3). They have all ran well,
albeit without support for directory indexing. None have run with your
patch. (I may not be a programmer, but I do know how to test.)


J.L. Hill

On Tue, Sep 18, 2012 at 12:37 PM, Mark Montague <> wrote:

> On September 18, 2012 0:17 , PanaColina <> wrote:
>> Thank you for your response. I had assumed that there was some mechanism
>> either within Apache HTTP Server or within PHP-FPM for handling a URI
>> request that corresponds to a directory. It just seemed like such a basic
>> requirement, to me.
> Apache HTTP Server does support this for files that it serves itself.  But
> it is impossible, in general, for Apache HTTP Server to support directory
> indexing for files that it proxies to a back-end server.  For example,
> let's say you have a front-end web server running httpd responding to
> requests for that proxies things to a FastCGI server
> running on a completely different machine at  When
> httpd sees a request for /content/create/hotdog, it won't be able to tell
> whether this is a request for a file named "hotdog", a request for the
> index of a directory named "hotdog", or whether this is a RESTful request
> to create a resource named "hotdog".  This is because the front-end web
> server isn't able to see the back-end server's configuration, and the
> back-end server may not even serve files from a filesystem, it may
> dynamically interpret all URI paths, it may serve them out of a database,
> or it may do something else entirely.  All Apache HTTP Server can do in
> this case is pass the request along to the back-end server and let the
> back-end server interpret what the request actually means.
> I agree that PHP-FPM should support a directory indexing mechanism, but it
> currently does not.  You may want to ask on the relevant PHP mailing lists
> whether this is a problem for anyone else and whether there are any plans
> to add this functionality to PHP.
>  I understand your point about a RewriteRule for matching directories,
>> although I have not been able to come up with a regex that would match any
>> directory at any depth, eg: /subdir, /subdir/subsubdir etc., but I am no
>> regex expert. I don't think a separate RewriteRule for each subdirectory
>> would be reasonable.
> You should not have a rule for each subdirectory.  Instead, have a rule
> that only gets triggered if the URI path happens to be for a directory, any
> directory, at any level.  The way to do this is by putting a RewriteCond
> directive before your rewrite rule, like this:
>         RewriteCond %{REQUEST_FILENAME} -d
>         RewriteRule ^/?(.*)$ fcgi://socket=%2fusr%2flocal%**
> 2fphp-fpm%2fvar%2frun%2ffpm-**php.sock/usr/local/apache/www/**$1index.php
> [P,L]
> Note that the write rule is matching the entire URL path, regardless of
> whether it contains multiple slashes or not.  If you requested
the trailing slash) then %{REQUEST_FILENAME} would be
> /usr/local/apache/www/subdir/**subsubdir/ and the RewriteCond would be
> true if this existed in the filesystem and was a directory.  The capture
> part of the RewriteRule, "(.*)" would then match subdir/subsubdir and the
> request would be proxied to fcgi://socket=%2fusr%2flocal%**
> 2fphp-fpm%2fvar%2frun%2ffpm-**php.sock/usr/local/apache/www/**
> subdir/subsubdir/index.php
>  I tried your patch (thank you) on php-5.4.6 and php-5.4.7 without
>> success. Running the patch, there was a small offset in each case (8
>> lines), but building failed:
>>     /usr/local/src/php-5.4.6/sapi/**fpm/fpm/fpm_main.c: In function
>>     ‘fpm_cgibin_saveenv’:
>>     /usr/local/src/php-5.4.6/sapi/**fpm/fpm/fpm_main.c:1388: error:
>>     ‘tsrm_ls’ undeclared (first use in this function)
>>     /usr/local/src/php-5.4.6/sapi/**fpm/fpm/fpm_main.c:1388: error:
>>     (Each undeclared identifier is reported only once
>>     /usr/local/src/php-5.4.6/sapi/**fpm/fpm/fpm_main.c:1388: error: for
>>     each function it appears in.)
>> I assumed I could simply declare tsrm_ls at the beginning of the function
>> (obviously, I am not a programmer). While I tried several basic ideas for
>> declaring it, and each one allowed php to compile without a build error,
>> php-fpm would not start after it was installed.
> You may want to take this part of the discussion to a PHP mailing list.
>  But you can't simply declare something to make a symptom (error) go away,
> you would have to actually solve the underlying problem (whatever it may
> be) correctly.  In this case, my patch doesn't deal with that symbol at
> all, it's something that gets used in ZTS builds of PHP, so I suspect that
> you're not compiling PHP correctly.   Are you able to successfully build
> PHP without my patch and get a working php-fpm?
>  I appreciate this functionality is not necessary for every website, but I
>> am still surprised there is no real support for this, given that php-fpm is
>> not considered experimental as of httpd-2.4.
> Again, this is not a problem with Apache HTTP Server.  php-fpm is a part
> of the PHP project, and the functionality that is missing is missing from
> PHP, not from Apache HTTP Server.  But there are workarounds that you can
> do in Apache HTTP Server, such as the mod_rewrite based workaround that I
> discuss above.
> --
>   Mark Montague

View raw message