|Summary:||FcgidWrapper does not support paths containing a space|
|Component:||mod_fcgid||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Severity:||normal||CC:||david.graf, flw, gls|
|Attachments:||Patch to honor quoted FcgidWrapper command and arguments|
Description mumu 2011-05-13 09:06:46 UTC
Prereq: Have a PHP installed in a path containing a space, for example C:\Program Files\PHP Based on that, the httpd.conf contains the following line: FcgidWrapper "C:/Program Files/php/php-cgi.exe" .php Current result: The Apache startup fails with the following error: The Apache service named reported the following error: >>> Wrapper C:/Program cannot be accessed: (720002)The system cannot find the file specified. . Expected: The Fcgid/Apache handles the path with a space correctly, so the wrapper is found successfully.
Comment 1 William A. Rowe Jr. 2012-02-29 18:22:14 UTC
*** Bug 52795 has been marked as a duplicate of this bug. ***
Comment 2 William A. Rowe Jr. 2012-10-29 19:13:20 UTC
Created attachment 29520 [details] Patch to honor quoted FcgidWrapper command and arguments Attached is a patch which corrects only the behavior of FcgidWrapper. The other directives for authnz/access checkers have not been corrected yet. Would appreciate validation of this patch on both unix and windows by others before applying it to trunk, particularly against some fcgid wrapper other than php. The patch continues the documented behavior of the FcgidWrapper, which claims to allow space separated args, e.g. FcgidWrapper "\"c:/Program Files (x86)/php-nts/php-cgi.exe\" -d date.timezone=America/Chicago" .php The modern phpinfo() complains bitterly if date.timezone is not set, making this a simple test that the command line value was used in place of the missing php.ini entry.
Comment 3 William A. Rowe Jr. 2012-10-29 20:07:23 UTC
*** Bug 52436 has been marked as a duplicate of this bug. ***
Comment 4 Ben Johnson 2012-11-05 15:23:53 UTC
This bug affects me, too. Here are two workarounds that can be employed until the proposed patch is integrated. 1.) Use the 8.3 file name, for example: #Path to php-cgi FcgidWrapper "C:/Progra~1/php/php-cgi.exe" .php (Thanks to http://www.php.net/manual/en/install.windows.apache2.php#96529 ) 2.) Create an NTFS junction point using the Windows Command Prompt, for example: mklink /J "C:\php" "C:\Program Files\php"
Comment 5 William A. Rowe Jr. 2012-11-16 18:33:22 UTC
Committed and anticipated in 2.3.8 tag.
Comment 6 edw.tests 2013-02-25 11:08:35 UTC
Will this patch also fix arguments to the wrapper? For instance, right now the following is impossible with 2.3.7: FcgidWrapper "c:/php/bin/php-cgi.exe -d open_basedir='C:\\Shared Files\\'" .php While this works fine: FcgidWrapper "c:/php/bin/php-cgi.exe -d open_basedir='C:\\Shared_Files\\'" .php I know I can work around this by either renaming my paths or using a script file instead of php-cgi.exe directly, but this gets extremely annoying when developing and testing with both mod_php and fcgi. The current situation forces the use of a separate configuration (wrapper) file for each virtual host. This is not very nice since it's easy to forget to update the wrapper script. If this directive supported spaces in its arguments, It would be possible to keep everything together in the virtual hosts configuration file like: <IfModule mod_php5.c> php_admin_value open_basedir "C:\\Shared Files\\" </IfModule> <IfModule fcgid_module> <Files ~ "\.php$"> AddHandler fcgid-script .php FcgidWrapper "c:/php/bin/nts/php-cgi.exe -d open_basedir='C:\\Shared Files\\'" .php </Files> </IfModule>
Comment 7 Gregg L. Smith 2013-03-29 06:30:40 UTC
Bill, this seems to have broken the use of double backslash. FcgidWrapper "C:\\php54\\php-cgi.exe" .php Wrapper C:php54php-cgi.exe cannot be accessed: (720002)The system cannot find the file specified. 2.3.8-dev @ r1411531
Comment 8 William A. Rowe Jr. 2013-04-05 06:04:34 UTC
(In reply to comment #7) > Bill, this seems to have broken the use of double backslash. > FcgidWrapper "C:\\php54\\php-cgi.exe" .php > > Wrapper C:php54php-cgi.exe cannot be accessed: (720002)The system cannot > find the file specified. Greg, I you have properly bisected the change, the very same behavior should be seen in directives like ErrorLog etc. Can you confirm that double-backslashes are generally faulty?
Comment 9 Gregg L. Smith 2013-04-22 18:21:14 UTC
No, I can confirm it doesn't affect any other directives that I've looked at and mod_fcgid 2.3.7 works fine with below config snippets. Tested again with 2.3.7 + just r1410528 patch. ServerRoot "C:\\Apache24" DocumentRoot "C:\\Apache24\\htdocs" ErrorLog "C:\\Apache24\\logs\\error.log" FCGID config FcgidInitialEnv PHPRC "c:\\php54" FcgidInitialEnv PATH "c:\\php54;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;" FcgidInitialEnv SystemRoot "C:\\Windows" FcgidInitialEnv SystemDrive "C:" FcgidInitialEnv TEMP "C:\\WINDOWS\\TEMP" FcgidInitialEnv TMP "C:\\WINDOWS\\TEMP" FcgidInitialEnv windir "C:\\WINDOWS" <Files ~ "\.php$"> Options +ExecCGI AddHandler fcgid-script .php FcgidWrapper "c:\\php54\\php-cgi.exe" .php </Files> Once FcgidWrapper is changed to "c:/php54/php-cgi.exe" it all works again w/ r1410528. phpinfo() shows that the FcgidInitialEnv are also not affected. PATH: c:\php54;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem; PHPRC: c:\php54 SystemRoot: C:\Windows TEMP: C:\WINDOWS\TEMP TMP: C:\WINDOWS\TEMP WINDIR: C:\WINDOWS
Comment 10 edw.tests 2013-10-08 15:01:30 UTC
I just upgraded my dev server to mod_fcgi 2.3.9 final (from the apache lounge), and guess what? Yes, exactly, the double backslash is broken. I had to change it to forward slashes everywhere. Nice...not. It's not even documented as a breaking change.
Comment 11 William A. Rowe Jr. 2018-11-07 21:09:27 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd. As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd. If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question. If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with. Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.