We are unable to use 'exec' with Server Side Includes to execute commands and get the output on a Windows system using either 2.2.17 or 2.0.64. It does appear to work on 1.3.28.1. We have tried Windows 2003 SP2, Windows XP SP3, and an older Windows 2000 system. We used the documentation at: http://httpd.apache.org/docs/2.2/howto/ssi.html To reproduce: - Configure SSI. In the .conf: a) In the <Directory> section of the DocumentRoot, change the Options value so it has 'Includes'. We used: Options All b) Uncomment these lines: AddType text/html .shtml AddOutputFilter INCLUDES .shtml - Place an 'index.shtml' file in the DocumentRoot dir root. We used a simple one with the following contents: <br/> <!--#set var="FOOBAR" value="SSI is working" --> <!--#echo var="FOOBAR" --> <br/> <pre> Here is output of the internal 'dir' command: <!--#exec cmd="dir" --> </pre> <br/> Here is output from exec of 'c:/windows/system32/hostname.exe': >><!--#exec cmd="c:/windows/system32/hostname.exe" --><< - Start the server and access the 'index.shtml' document in your browser. The output shows the 'SSI is working' string, but there is no output from the 'dir' and 'hostname.exe' execs for 2.x, but there is for 1.3.28.1 It doesn't seem to matter whether the server is started as a service or from the command-line, but when started from the command-line we have noticed cmd-prompt windows popping up very briefly and then disappearng, as if the exec'ed commands may be running within them. Note: The config for 1.3.28.1 is slightly different per the 1.3 documentation: http://httpd.apache.org/docs/1.3/howto/ssi.html It uses: AddHandler server-parsed .shtml whereas 2.x uses: AddOutputFilter INCLUDES .shtml
The exec construct doesn't correspond to a "command line" per say. dir in your example is not expected to work. You didn't invoke cmd.exe. That hostname.exe fails is interesting. What about backslashes? In any case exec is not recommended, include virtual is.
I included the 'dir' because it was the provided example for Windows from the 'Executing commands' section of the 'Apache Tutorial: Introduction to Server Side Includes' doc: http://httpd.apache.org/docs/2.2/howto/ssi.html I agree that the invocation of an actual .exe file is of more interest however. I have tried a variety of variations on the slashes (backslashes, double backslashes, escaped backslashes) and have so far still been unable to get it to work.
I'm having no problem invoking a exe in the docroot/scriptalias, as stated, the include virtual= and file system doesn't map 1 to 1. I don't think even if it did hostname.exe would work cause it doesn't print out the content type. Moving a copy into the docroot I get. [Thu Feb 24 22:51:48 2011] [error] [client ::1] malformed header from script. Bad header=MYPUTER3: HOSTNAME.EXE MYPUTER3 is correct. A compiled perl script helloworld.exe works without problem since it prints out the content-type. I was using: Server version: Apache/2.2.18-dev (Win32) Server built: Jan 26 2011 11:51:40 I'd call this Invalid in the case of 2.2.x as it's a user produced error looking at the examples given. 2.3.11-dev is another story it seems but I need to test further on it.
(In reply to comment #3) > I'm having no problem invoking a exe in the docroot/scriptalias, as stated, the > include virtual= and file system doesn't map 1 to 1. I don't think even if it > did hostname.exe would work cause it doesn't print out the content type. Moving > a copy into the docroot I get. > > [Thu Feb 24 22:51:48 2011] [error] [client ::1] malformed header from script. > Bad header=MYPUTER3: HOSTNAME.EXE > MYPUTER3 is correct. This PR is about #exec cmd=foo which is supposed to substitute the output of a (non-CGI) regular executable.
Some updates about trying to use ssi exec after doing some more experimentation with this: I still have not been able to use exec to invoke an .exe and see its output but have been able to use it to show some output from an invoked Windows batch file. If Windows internal commands (ex: dir, ver, vol, date /t, time /t) are invoked within the batch file then their output will appear in the .shtml page. However, I have not been able to get the output of external commands (ex: hostname.exe, netstat.exe, ipconfig.exe, etc.) that are invoked from the batch file to appear. I have tried various .exe invocations from within the batch file to no avail (ex: 'hostname.exe', 'cmd /c hostname.exe', etc.). Any thoughts on how to get the output of a .exe using the ssi exec? Below is an example of the latest test files and output. You can see that hostname.exe produced no output either when invoked directly by exec or when used within the batch file. However, hostname.exe does produce output to the console when the ssitest.cmd is invoked directly on the command-line. index.shtml --------------------------------------------------------- <br/> <!--#set var="FOOBAR" value="SSI is working" --> <!--#echo var="FOOBAR" --> <br/> <pre> Here is output from exec of 'd:\temp\ssitest.cmd': >><!--#exec cmd="d:\temp\ssitest.cmd" --><< </pre> <br/> Here is output from exec of 'c:\windows\system32\hostname.exe': >><!--#exec cmd="c:\windows\system32\hostname.exe" --><< <br/> ssitest.cmd batch file (invoked by within index.shtml by exec): --------------------------------------------------------------- @echo off @echo "ssitest.cmd ran" dir hostname.exe @echo on Output seen in my browser (for http://localhost/index.shtml): ------------------------------------------------------------ SSI is working Here is output from exec of 'd:/temp/ssitest.cmd': >>"ssitest.cmd ran" Volume in drive D is D_DRIVE Volume Serial Number is 14E9-D859 Directory of D:\Apache_2217\htdocs 03/02/2011 01:50 PM . 03/02/2011 01:50 PM .. 06/22/2010 04:46 PM 20 cache2.html 11/20/2004 03:16 PM 44 index.html 03/02/2011 01:53 PM 363 index.shtml 03/02/2011 01:24 PM 575 index.shtml_sav 02/17/2011 10:49 AM 614 index.shtml_test1 02/21/2011 11:25 AM 323 index.shtml_use 6 File(s) 1,939 bytes 2 Dir(s) 420,219,654,144 bytes free << Here is output from exec of 'c:\windows\system32\hostname.exe': >><<
Note that httpd runs as a service as the designated user (usually LocalSystem). That means several environmental factors are going to potentially interfere in various ways with operation. Running httpd in a console is one way to differentiate service-oriented flukes from the possible user/desktop/shell expectations.
Good thought, but it doesn't seem to have made any difference. I had been running it as a service under the LocalSystem account, so tried both running the service under a different account and starting the server from the command-line. For both cases, the output was still exactly as shown in my last update with no output from hostname.exe appearing.
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.