Bug 50814 - SSI exec not working on Windows (Apache 2.x)
Summary: SSI exec not working on Windows (Apache 2.x)
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_include (show other bugs)
Version: 2.2.17
Hardware: PC Windows Server 2003
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2011-02-21 15:35 UTC by RW Sagraves
Modified: 2018-11-07 21:08 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description RW Sagraves 2011-02-21 15:35:33 UTC
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': &gt;&gt;<!--#exec cmd="c:/windows/system32/hostname.exe" -->&lt;&lt;


- 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
Comment 1 William A. Rowe Jr. 2011-02-21 16:12:58 UTC
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.
Comment 2 RW Sagraves 2011-02-24 12:07:11 UTC
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.
Comment 3 Gregg L. Smith 2011-02-25 02:07:43 UTC
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.
Comment 4 Eric Covener 2011-02-25 07:22:50 UTC
(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.
Comment 5 RW Sagraves 2011-03-02 14:29:23 UTC
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': &gt;&gt;<!--#exec cmd="d:\temp\ssitest.cmd" -->&lt;&lt;
</pre>
<br/>
Here is output from exec of 'c:\windows\system32\hostname.exe': &gt;&gt;<!--#exec cmd="c:\windows\system32\hostname.exe" -->&lt;&lt;
<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': >><<
Comment 6 William A. Rowe Jr. 2011-03-02 16:56:18 UTC
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.
Comment 7 RW Sagraves 2011-03-03 12:16:43 UTC
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.
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:48 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.