Re: [cgiwrap-users] cgiwrap php continued
Brought to you by:
nneul
Menu
▾
▴
Re: [cgiwrap-users] cgiwrap php continued
|
From: Brian A. <ba...@no...> - 2001-09-06 21:05:07
|
You sure go above and beyond the call of duty troubleshooting with a newborn around, but I'm sure glad you did. The suggestion to compile php with the option "--enable-discard-path" works perfectly. I had it set aside in what I thought were all of php's configure security options, and I was going to add them in one by one after I got a basic setup working. Thanks again. Brian Allen On Wed, 5 Sep 2001, Nathan Neulinger wrote: > Argh... damn... php is using PATH_TRANSLATED to locate the script. WTF > does it need to be doing that when it is passed the script's location w/ > #!. > > ---- > cessna(70)> printenv > QUERY_STRING= > SCRIPT_NAME=/cgi-bin/cgiwrap/nneul/test.php > PATH_INFO= > PATH_TRANSLATED=/users/nneul/public_html/cgi-bin > REQUEST_METHOD=GET > cessna(71)> /users/nneul/public_html/cgi-bin/test.php > cessna(72)> setenv PATH_TRANSLATED > /users/nneul/public_html/cgi-bin/test.php > cessna(73)> /users/nneul/public_html/cgi-bin/test.php > X-Powered-By: PHP/4.0.6 > Content-type: text/html > > <html> > <head> > <title>PHPTest</title> > Testing1234 > ---- > > Well, that means that the path-translated setting in cgiwrap is STILL > not right. I'll see about fixing that. I've asked people to send me > information on correct behavior of this variable before, but have never > gotten an answer, or any interest in changing the behavior, despite it's > having been altered several times in cgiwrap's history. > > If we set SCRIPT_FILENAME, which cgiwrap definately does, it still does > not work. > > Ah ha! If you build php with --enable-discard-path, it works. Apparently > php has some code in it to locate the script using path-translated and > such so that people can install php directly inside cgi root (Ok, I > relaly don't understand what would possess someone to do that. That > sounds just like putting perl.exe inside cgi dir on windows... > Whatever.) > > Anyway, seems that adding --enable-discard-path will correct the > problem. > > -- Nathan > > Nathan Neulinger wrote: > > > > Brian Allen wrote: > > > > > > Hi Nathan, > > > I still can't get php to work with cgiwrap or php-cgiwrap. Here > > > are the main points in my process: > > > > > > 1) Download the patch per Piotr's instance, cgiwrap-3.7, and php-4.0.6. > > > 2) Apply patch to cgiwrap-3.7. (I verified by hand that the patch was > > > applied correctly.) > > > > Ok. That patch should not be necessary unless you are trying to run php > > scripts without having a valid #! line and/or not executable. (It's a > > patch for people too lazy to do normal script installation.) > > > > > 3) Configure php with the following command: > > > ./configure --disable-force-cgi-redirect > > > 4) Configure cgiwrap with the following command: > > > ./configure --with-cgi-dir=www/cgi-bin --with-httpd-user=www > > > --with-php=/usr/local/bin/php > > > 5) Edit apache's httpd.conf file: > > > AddHandler php-cgiwrap .php > > > Action php-cgiwrap /cgi-bin/php-cgiwrap > > > > > > I have attached two truss output files which I describe below: > > > > > > file1: command1: > > > ------------ -------------------------------------------------------- > > > apache.truss truss -r all -w all -f -o apache.truss ./apachectl start > > > > > > (Note: after I ran the above command, I first tried the following url: > > > > > > http://kosh.umuc.edu/cgi-bin/php-cgiwrap/ballen/hello.php > > > > > > Then I tried this url: > > > > > > http://kosh.umuc.edu/cgi-bin/php-cgiwrap/ballen/test.cgi > > > > > > I did this so I could compare a successful call of php-cgiwrap versus a > > > call which produces an error.) > > > > > > file: command2: > > > --------- --------------------------------------------------- > > > php.truss truss -r all -w all -f -o php.truss ./php hello.php > > > > > > (Note: I wanted this truss output so I could compare the previous php > > > failure versus a successful php call.) > > > > > > I still think the problem, or maybe it's just a symptom, is what I > > > mentioned before, which is that the script name is not being passed to > > > php-cgiwrap because the hello.php script is never opened while test.cgi is > > > opened. And in the php.truss output, the script hello.php is opened. > > > > Ok. Depending on when the open occurs, it could be cgiwrap trying to > > execute the script, or it could be cgiwrap trying to find the script - > > although those should only be stat calls. > > > > One possibility is that php is completely ignoring the fact that it was > > executed via #! and is trying to find the script itself, despite already > > knowing exactly where the script is. > > > > Since I'm not having any luck diagnosing your problem here, I'm going to > > try and set up php locally and see if I can reproduce your problem. > > (However, I can't promise I'll get to it today, as I am home with a new > > baby (born 8/31), so am pretty swamped.) > > > > Only thing I can suggest at the moment, is try to reproduce the cgiwrap > > execution environment variables (use that test script I mentioned) and > > see what is different in that environment from the environment where the > > script works. Then see if there is a minimal change necessary to get it > > to function. (That's what I'll do as soon as I get it installed.) > > > > -- Nathan > > > > ------------------------------------------------------------ > > Nathan Neulinger EMail: nn...@um... > > University of Missouri - Rolla Phone: (573) 341-4841 > > CIS - Systems Programming Fax: (573) 341-4216 > > -- > > > ------------------------------------------------------------ > Nathan Neulinger EMail: nn...@um... > University of Missouri - Rolla Phone: (573) 341-4841 > CIS - Systems Programming Fax: (573) 341-4216 > |
