ID: 12264 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IIS related Operating System: Win2K Server PHP Version: 4.0.6 New Comment: Hmm, looks like my patch thing didn't quite work [for one, PATH_INFO isn't being set right, then I think there are also some memory leaks]) ... I had an old very hacky patch around here that I ended up reverting to for now. A proper fix for this problem would be great :) Previous Comments: ------------------------------------------------------------------------ [2001-07-19 14:29:07] [EMAIL PROTECTED] Hello, The scripts that we are running use PATH_INFO to determine where a user is trying to access, and this became a problem when we switched over from using Apache to using IIS. Once we made the switch from Apache to IIS we were getting continual CGI Errors (like virtually every single hit was a CGI Error) [ and this was not because of permissions ] As it turns out, the only pages where we would not get a CGI error was the root page, which had an empty PATH_INFO. Here's an example: Our root script is /test.php. If I requested /test.php everything would work fine; However if I requested /test.php/hello/world I would get a CGI Error (under IIS). Under Apache I would get the proper results -- it would run /test.php and PATH_INFO would be /hello/world. But anyways - after spending some time poking around the PHP source I found that PHP was trying to execute the wrong file! In the above example, it was attempting to run /test.php/hello/world instead of /test.php (SCRIPT_NAME was being to /test.php). To me it looked like IIS was setting PATH_INFO and PATH_TRANSLATED differently than PHP was expecting, so I made a change the the source so that it would modify those two until they were in working order. I'm not sure if my change is correct - but it did fix the problem). (Note: The problem is independent of the actual script - any script where you put stuff on the URL in this manner will have this problem) ===== What follows now is the output that I had PHP give on what it was trying to run. The first is the original version that didn't work, followed by the version with the changes that I made, and the proper results: In both of the cases, the requested URL was: http://192.168.1.2/test.php/hello/world Original (non-working) version ------------------------------ PHP Output follows SG(request_info).path_translated: (null) PATH_INFO : /test.php/hello/world SCRIPT_NAME : /test.php SG(request_info).request_uri = /test.php/hello/world php_fopen_primary_script(): filename = C:\web\fcsweb\test.php\hello\world php_fopen_primary_script(): path_info = /test.php/hello/world ===== So you can see that in the original request it is trying to run the wrong script. With the changes I made, I now get the following: New (working) version --------------------- PHP Output follows SG(request_info).path_translated: C:\web\fcsweb\test.php PATH_INFO : /hello/world SCRIPT_NAME : /test.php SG(request_info).request_uri = /hello/world php_fopen_primary_script(): filename = C:\web\fcsweb\test.php php_fopen_primary_script(): path_info = /hello/world ===== Some more information on our system: OS: Win2k Server SP1 Webserver: IIS4 PHP: 4.0.6 CGI mode And finally, the patch for the changes I made to cgi_main.c are at: http://div.dyndns.org/jah/php/iis_cgi_path_fix.patch I've never submitted a patch before, so I don't know if it's done in the right manner... Hopefully I've analyzed this whole issue somewhat correctly... :) Thanks! -Jah ------------------------------------------------------------------------ Edit this bug report at http://bugs.php.net/?id=12264&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
