On Wednesday 24 May 2017 03:40:54 Lester Caine wrote: > On 24/05/17 02:05, John Iliffe wrote: > > On Tuesday 23 May 2017 02:40:03 Lester Caine wrote: > >> On 23/05/17 02:41, John Iliffe wrote: > >>> The Apache directive invoking this script is: > >>> ProxyPassMatch "^/.*\.php(/.*)?$" > >>> fcgi://127.0.0.1:9015/httpd/iliffe/ > >> > >> ProxyPassMatch ^/(.*\.php(/.*)?)$ > >> fcgi://127.0.0.1:9015/httpd/iliffe/$1 was your original line, and > >> this should have resulted in the right trimming of slashes while I > >> think you are currently getting the double slash because of the > >> trailing one in your current string. > > > > Please ignore this following paragraph. It was an attempt at a > > minimalist ProxyPassMatch that would bypass any regex errors. It > > isn't useful in the real world so I dropped trying it. I think you > > got that info from the Apache mailing list. > > I suggested it simply because it would bypass some errors ;) > > >> ProxyPassMatch ^/info$ > >> fcgi://127.0.0.1:9015/httpd/iliffe/i_phpinfo.php and > >> http://localhost/info should work ... but is /httpd REALLY a root > >> folder? I'm getting /srv/www/htdocs as the default root, and I > >> switch to /srv/website/test.com for each website ... > > > > Some further info: > > > > Yes, /httpd is the root directory for the web pages. The production > > server has a lot of named virtual hosts on it and each one has a > > document root of /httpd/<server name>/ and the test server is set up > > the same way. The test server is www.iliffe.ca and its document root > > thus becomes /httpd/iliffe plus a few subs below that where needed. > > In this case, there are no additional subs. > > One of the major problems with Linux is the way each distribution > modifies just where it installs key applications and how it manages > them. I'm on SUSE myself and apart from a couple of attempts at other > distros when the SUSE guys just totally lost the plot, I've been with > that since version 6. My problem is installing later APACHE/PHP builds > while maintaining the stable SUSE installs ... and getting paths right > teds to be the problem. > > > When I tried the $1 extension as you suggested it didn't work, see > > previous memo; so I removed the $1 and also the last '/' in the > > ProxyPassMatch directive and now php-fpm has the correct path and > > file but without the double '//'. So, this is one case where a > > trailing / on a directory does not work/isn't required. Here is the > > strace record: > > > > ------------------------------- > > 5254 20:14:55 lstat("/httpd/iliffe/i_phpinfo.php", > > {st_mode=S_IFREG|0644, st_size=213, ...}) = 0 > > -------------------------------- > > > > php-fpm received a 0 from lstat (file exists), is a regular file > > (S_IFREG) and is readable (0644). So that makes no difference to the > > result. php-fpm still backs down the directory tree and then tries > > to stat the wrong file name. Just for completeness, here is the > > php-fpm log entry: > > > > ---------------------------------- > > [23-May-2017 20:14:55] WARNING: [pool www] child 5254 said into > > stderr: "ERROR: Unable to open primary script: > > /httpd/iliffe/i_phpinfo.php (No such file or directory)" > > --------------------------------- > > THAT is telling me that /httpd/iliffe/i_phpinfo.php is not the path to > the file. Bit like one gets with windows where it hides the real > physical location and only gives you a 'user' view of the path. My copy > of Apache is using wwwrun:www user when it is running, so all of the > /<server name> folders and files have that user name and group, but even > with that php should be able still to read the file so I'm still > thinking the path is wrong in some way. A quick search on Fedora give > /var/www/html/ as the default where SUSE gives me /srv/www/htdocs ... > > > I haven't been able to find out yet if the parameter data is picked up > > when the Apache directive is coded this way. (eg: > > i_phpinfo.php?a=b&c=d) > > > > I seem to be getting a good argument here for backing off to PHP5! > > If there was a good security reason for changing the PHP5.4 machines I'm > still running then I'd move, and eaccelerator still provides all the > speed improvement I need, so I'm not surprised three quarters the world > has yet to even move to a higher version of PHP5 ... and less that 5% > are using PHP7 front facing. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
