I can not reproduce this. Please give more information about your setup: How did you configure PHP in httpd.conf? What changes did you make into php.ini? (is the right php.ini loaded?) 

And DO NOT paste full php.ini here! Make a unified diff against php.ini-dist (or if you used php.ini-recommeded as basis, against that one)

Greetings, and thanks!  I am travelling this week, so please forgive the reply latency.

Note that I am running a compiled Apache 2.0.53, not a standard SuSE 9.1 distro and am using default file placements.  I verified by using phpinfo() that the expected php.ini is being loaded and the build date of libphp5.so is also correct.  The only change to httpd.conf for php5 was to add the..

LoadModule php5_module modules/libphp5.so

My php.ini is based on a slightly older php.ini-recommended, but is diffed against the 3/19 snapshot of same.  This server will be the production server, but errors are turned on, for the moment, to facilitate finding installation, configuration and porting problems.  The differences are:

--- php.ini-recommended 2005-02-28 19:30:02.000000000 -0600
+++ /usr/local/php5/lib/php.ini 2005-03-19 11:48:54.000000000 -0600
@@ -272,7 +272,7 @@
 disable_classes =

 ; Colors for Syntax Highlighting mode.  Anything that's acceptable in
-; <span style="color: ???????"> would work.
+; <font color="??????"> would work.
 ;highlight.string  = #DD0000
 ;highlight.comment = #FF9900
 ;highlight.keyword = #007700
@@ -280,10 +280,6 @@
 ;highlight.default = #0000BB
 ;highlight.html    = #000000

-; If enabled, the request will be allowed to complete even if the user aborts
-; the request. Consider enabling it if executing long request, which may end up
-; being interrupted by the user or a browser timing out.
-; ignore_user_abort = On

 ;
 ; Misc
@@ -354,12 +350,12 @@
 ; instead (see below).  Keeping display_errors enabled on a production web site
 ; may reveal security information to end users, such as file paths on your Web
 ; server, your database schema or other information.
-display_errors = Off
+display_errors = On

 ; Even when display_errors is on, errors that occur during PHP's startup
 ; sequence are not displayed.  It's strongly recommended to keep
 ; display_startup_errors off, except for when debugging.
-display_startup_errors = Off
+display_startup_errors = On

 ; Log errors into a log file (server-specific log, stderr, or error_log (below))
 ; As stated above, you're strongly advised to use error logging in place of
@@ -484,7 +480,7 @@
 ;default_charset = "iso-8859-1"

 ; Always populate the $HTTP_RAW_POST_DATA variable.
-;always_populate_raw_post_data = On
+always_populate_raw_post_data = On


 ;;;;;;;;;;;;;;;;;;;;;;;;;
@@ -492,7 +488,7 @@
 ;;;;;;;;;;;;;;;;;;;;;;;;;

 ; UNIX: "/path1:/path2"
-;include_path = ".:/php/includes"
+include_path = ".:/usr/local/php5/lib/php:/usr/share/php"
 ;
 ; Windows: "\path1;\path2"
 ;include_path = ".;c:\php\includes"
@@ -937,7 +933,7 @@
 ;
 ; where MODE is the octal representation of the mode. Note that this
 ; does not overwrite the process's umask.
-;session.save_path = "/tmp"
+session.save_path = "/var/lib/php/session"

 ; Whether to use cookies.
 session.use_cookies = 1
@@ -1025,7 +1021,7 @@
 ;   in publically accessible computer.
 ; - User may access your site with the same session ID
 ;   always using URL stored in browser's history or bookmarks.
-session.use_trans_sid = 0
+session.use_trans_sid = 1

 ; Select a hash function
 ; 0: MD5   (128 bits)
@@ -1150,6 +1146,10 @@
 ; Default proxy password.
 ;pfpro.proxypassword =

+[Sockets]
+; Use the system read() function instead of the php_read() wrapper.
+sockets.use_system_read = On
+
 [com]
 ; path to a file containing GUIDs, IIDs or filenames of files with TypeLibs
 ;com.typelib_file =

I still can not reproduce this problem with using exactly same  php.ini as you do. And you really need to put something more into httpd.conf to enable PHP than just that LoadModule line.
So HOW have you configured PHP in there?

The following is a unified diff of httpd.conf and httpd-std.conf.  Am I missing something?  I confess I am a bit out of my depth, and am more than willing to read any documentation you suggest.  (BTW, I am not having this problem on my FC3 box).

--- httpd.conf  2005-03-19 12:38:29.000000000 -0600
+++ httpd-std.conf      2005-02-21 13:08:40.000000000 -0600
@@ -229,8 +229,6 @@
 #
 # Example:
 # LoadModule foo_module modules/mod_foo.so
-LoadModule php5_module        modules/libphp5.so
-AddType application/x-httpd-php .php
 #

 #
@@ -393,7 +391,7 @@
 # negotiated documents.  The MultiViews Option can be used for the
 # same purpose, but it is much slower.
 #
-DirectoryIndex index.html index.html.var index.php
+DirectoryIndex index.html index.html.var

 #
 # AccessFileName: The name of the file to look for in each directory

And you don't set any funny things in ANY .htaccess file?
And you're REALLY running latest CVS snapshot?
Get this:

  http://snaps.php.net/php5-latest.tar.gz

And do this (EXACTLY THIS):

# ./configure --disable-all --disable-cli --with-prefix=/usr/local/php5 --with-apxs2=/usr/local/apache2/bin/apxs
# make install-sapi

Then first STOP apache and make sure it really is dead,
and after making sure it was not still running, start it.

Here be gremlins!

FYI - I had not setup any .htaccess files, at all.  I was running the 3/19 snapshot, but reloaded the latest as you asked, then rebuilt using your suggested configure options.

MY TEST SCRIPT WORKED!  Hurray!

So I rebuilt using my configuration and my script still worked.  I tested my app and....

the include_path was not being correctly set.  Other changes to php.ini were reflected in phpinfo(), but changes to the include_path were not (I verified each directory existed).  I fussed with that for a while and got my app running by setting the path within the script.  (Not good!).

So I decided to run my test script under Mozilla (I had been using Konqueror) and IT FAILED as before.  Furthermore, it now failed under Konqueror.  Only when I stopped Mozilla would the test script run correctly under Konqueror.

At this point, I have no clue what is failing and will continue testing.  

Thanks for your help.  Obviously, if you have any suggestions for me, I would appreciate hearing them (perhaps debugging techniques I, as a long-time 'C' programmer, might employ).  I don't think any further efforts on your behalf are required.