XML Problem

[keneck]

I'm getting a very strange result from a PHP process. The file runs as a scheduled task on the server and is supposed to retrieve data from a weather service that is then written to an XML file. This process was working fine before a server crash.

Since the server was restored, the script mirrors its own contents into the file. It correctly overwrites the existing file, but with its own script instead of the XML data. Running the same script from a different server produces the correct output.

Has anyone ever experienced anything like this? The server is running Windows 2003. PHP 5 is installed and working. And all of this was working before the server had to be restored.

Thanks for any ideas.

 

[sleipnir214]

If you point your browser to a PHP script, and the web server on which the script resides does not know how to run PHP scripts, then that web server will just send the text of the script to the browser.

How are you running the script?



Want the best answers? Ask the best questions! TANSTAAFL!

 

[keneck]

Thanks for responding. The script is on a server that is primarily used for running ColdFusion applications. The PHP script is run from a scheduled task in CF Administrator. At the scheduled time, the CF Server retrieves the designated page which contains code that links to the national weather service. The script is actually one provided by the NWS. The script retrieves the weather data and via CF Administrator, writes an XML document containing the data. We later parse the XML document using CF to transfer data to SQL Server.

This process has been runnning under the same conditions for about 2 years and can still be run from another server without problems. It ran this way on the current server until the server experienced some major problems and had to be completely restored. Since the restoration, the problem has occurred. We don't think it is specifically a PHP problem, but something different about the server.

The hosting provider has been working with us to try to resolve the issue, but none of us can determine why it is happening now. Changing permissions, replacing files with copies known to work, stopping and starting the CF server have all had no effect. We are stumped.

 

[keneck]

Just to clarify further, here is a link the problematic server. The fact that this page runs indicates that PHP is okay. The problem has to be in the server, but we can't think of anything yet in the server that would produce the bad result.

PHP Link:

http://206.188.8.194/test.php

 

[sleipnir214]

Does the offending PHP script use "<?....?>" to designate a block of code to be executed, or does the script use "<?php...?>"?

"<?php...?>" is the standard. But you can use "<?....?>" if and only if the setting "short_open_tag" is set to "on".

PHP may even allow us use ASP-like blocks using "<%....%>" if and only if in php.ini the setting "asp_tags" is set to "on".

Are your php.ini settings compatible with your script?



Want the best answers? Ask the best questions! TANSTAAFL!

 

[keneck]

The script that is running uses the "<?php...?> block. The settings for PHP are the same as before the server was restored. I'm now wondering if there is a problem in the CF server since it is responsible for dealing with the results returned by the PHP script. Have no clue as to what that problem might be, but fishing is called for at this point.

 

[sleipnir214]

The only thing I can tell you is to get CFServer out of the mix. If possible, run from a command prompt whatever it is that CFServer is supposed to run. Does the PHP script work correctly there?



Want the best answers? Ask the best questions! TANSTAAFL!

 

[KingCrab]

your mime type is not set correctly for PHP. this would pass the contents of the PHP file instead of running it and having the PHP file send back the XML. Your server thinks PHP is a plain/text file

 

[keneck]

Thanks for the suggestion. We rechecked that and the IIS setting is okay. We have run a couple of other PHP files through the scheduled task interface and they return the correct results e.g. a file that writes some simple XML returns the XML and it is written to a file properly.

All the files for this process are on a second server that we have used in the past for development only. Running the same process there returns the correct result. We have checked the output file and it has valid XML. We then moved all the files from the development server to the production server. Still got the bad result.

So the problem still seems to be with PHP, but only on this server. The suggestion that the MIME type might be wrong seemed like a real possibility until we discovered that it wasn't.

The fact that other PHP files run okay led us to wonder about the integrity of the files on the server so replacing them with ones known to be working on the other machine seemed a reasonable idea except that it made no difference either.

So while the particular files seem to have a problem, they only have the problem on the production server. We need some other ideas about what on the server could be wrong and affect those particular files. They are using the nusoap.php and its associated class and library files, but we never needed to do anything special to have them work on the dev machine.

 

[sleipnir214]

What are the differences between the php.ini files on the two machines?



Want the best answers? Ask the best questions! TANSTAAFL!

 

[KingCrab]

Are the Execute permission set on the folder correctly?

 

[keneck]

Found the answer. It was indeed the php configuration file. Not sure why, since the original installation had worked. After the server crash, PHP had to be reinstalled. We did this using the "recommended" configuration file as had been done originally. Changing this to the "default" config instead solved the problem. While the default was described as appropriate for development, the other was considered to offer better security - that was why we chose it originally. Not sure why the change in the configuration would be required after the server was restored, but it may take a while to figure that out.

Thanks for the suggestions.