exec mangles header on Win32/IIS5.1?

maybl8r03

Hi all/interested,

I can't seem to confirm this, on 4 of the servers we run - things seem to be running fine except for one machine... The code is identical and I've made the dataset on all the machines uniform. We are running Java 1.4.1_05 JRE on the servers.

3 x Windows 2000 machines, 1 x XP Professional, the one that seems to give me the problem is a Windows 2000 machine (whereas the other two works fine).

Here is a snippet:

$execstr = "java org.apache.xalan.xslt.Process -IN \"{$quickreportdir}{$xmlfile}.xml\"  -xsl \"{$filename}\" -TEXT -OUT \"{$quickreportdir}{$finalfilename}.txt\"";

if (!empty($arErrors)) unset($arErrors);
$strScratch = @exec($execstr, $arErrors);
if (!empty($arErrors) && is_array($arErrors))
{
   // send errors to error log
}

The faulty machine parses and runs all the required process without any errors (I confirmed this on the command line) and then seems to mangle my headers. The desired page comes back in pure HTML tags like:

Content-type: text/html
X-Powered-By: PHP/4.3.3
Set-Cookie: PHPSESSID=c55772b40d8662c1e89fefc6dec25fa6; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache

<html>
<head>
.... snip snip snip ....

I've been tracing it to no end and it seems that the only time it doesn't happen if I do not call exec.

The other Java class on that particular machine (Apache FOP) works like a charm in the same fashion.

We've been shelling out to Java instead of using the Java extension due to ease of use. I know I should be doing the call to Java classes with the Java extension but just haven't got the time to deal with the various different installs of Java out there (with our clients).

Ideas??

maybl8r03

Oh configurations:

The problem machine is running PHP 4.3.3 with Zend Optimizer 2.1 which is identical to my development system. The php.ini files are also identical.

maybl8r03

The stranger thing here is that I hava another script that calls FOP in an identical fashion on that machine and it works as designed.

The question here is; exec/shell_exec should be a quiet function - i.e. it doesn't try to output anything to STDOUT but sends the last message back as a string or appends it to a second parameter (by reference), so why did this particular instance on just this one machine is my headers mangled by a mysterious character(s) that I cannot find. Frustration reigns. Trying to use the native PHP Java extension only opens a bigger can of worms so I'm back where I started on just this one problem on this one machine.