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
issues.
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.)
Regards,
J.L. Hill
On Tue, Sep 18, 2012 at 12:37 PM, Mark Montague <m...@catseye.org> wrote:
> On September 18, 2012 0:17 , PanaColina <panama.h...@gmail.com> 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 www.example.com that proxies things to a FastCGI server
> running on a completely different machine at backend.example.com. 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
> http://yourserver.example.com/**subdir/subdirsubdir/<http://yourserver.example.com/subdir/subdirsubdir/>(note
> 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
> m...@catseye.org
>
>
