Bug 51194 - FcgidWrapper does not support paths containing a space
FcgidWrapper does not support paths containing a space
Status: NEW
Product: Apache httpd-2
Classification: Unclassified
Component: mod_fcgid
2.2.14
PC Windows XP
: P2 normal with 3 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: PatchAvailable
: 52436 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2011-05-13 09:06 UTC by mumu
Modified: 2013-10-08 15:01 UTC (History)
3 users (show)



Attachments
Patch to honor quoted FcgidWrapper command and arguments (2.78 KB, patch)
2012-10-29 19:13 UTC, William A. Rowe Jr.
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.