At Jani's request, recreating this bug report with a password so I can edit it directly...

This condition has been present in PHP's 4.0.4pl1 through to snapshot version php4-200110030000

Basically what happens is that whenever we use an "extension=module.so" line in our php.ini, we see the headers generated by the "expose_php = yes" configuration condition, and the "Content-type:", and any session-related headers in the body content of a web page generated by PHP. The only way to make this go away is of course to not use loadable modules, which is not exactly optimal for us.

It happens with a range of modules, basically every one that we have tried. It also happens with "extension=non-existent-module.so".

However as Jani rightly said, there would be complaints all over the place about this one if it happened to everyone, so  it must be dependant on some other factor, ie. the OS.

There's some background information following this...

Oh, our config has been varied considerably through the various releases, due to customer demand for new features to be compiled in, but the latest version we've been using is:

./configure --with-mysql=/usr --with-gd --enable-force-cgi-redirect --with-config-file-path=/etc/php4/cgi/ --with-imap --enable-ftp --with-openssl --with-kerberos=/usr/kerberos --with-jpeg=/usr --with-pdflib --with-domxl --with-wbmp
--with-zlib=/usr --with-bz2

No doubt you'll email me if you need more info ;-)

K.

PS. For reference, because it's probably useful, this used to be "Bug #13176 Updated: Headers output in HTML body.", but I didn't put in a password, so I had to email updates, hence the new bug report.

>It doesn't seem to be related to "extension=module.so" where the module
>is already compiled in explicitly, or where it isn't. It also doesn't
>seem to be related to a specific module.
>
>I think you're right, though. I think it's probably a problem specific
>to PHP on a certain (RedHat) architecture.
>
>The best way to solve it looks to be to consider the mechanism involved
>in loading the modules, and seeing what code external to PHP is called,
>and what it might be doing that's nasty.
>
>So, here's what our ld.so is:
>
>"[root@fred cgi]# rpm -qi ld.so-1.9.5-8
>Name        : ld.so                        Relocations: (not
>relocateable)
>Version     : 1.9.5                             Vendor: Red Hat Software
>Release     : 8                             Build Date: Tue Aug 25
>10:55:21 1998
>Install date: Wed Jan 13 17:50:46 1999      Build Host: porky.redhat.com
>Group       : Libraries                     Source RPM:
>ld.so-1.9.5-8.src.rpm
>Size        : 251943                           License: BSD
>Packager    : Red Hat Software <bugs@redhat.com>
>Summary     : Shared library configuration tool and old dynamic loader
>Description :
>
>This package contains the shared library configuration tool, ldconfig,
>which
>is required by many packages. It also includes the shared library loader
>and dynamic loader for Linux libc 5."
>
>Also, it might be of import that we are compiling on a different machine
>to that which we are deploying the PHP binary (for security etc., we
>don't have compilers on our world-facing web servers, and hence have to
>compile elsewhere).
>
>But I don't know for sure. This is all rather in depth code stuff for
>me...
>
>> >> [2001-09-06 11:47:31] sniper@php.net
>> >>
>> >> Does this happen with certain script?
>> >All scripts for all of our customers it seems, until we remove all
>> >dynamic module loading in their php.ini.
>>
>> This is odd. Does plain vanilla php.ini-dist copied to php.ini work??
>>
>> >> Does this happen with latest CVS snapshot from
>> >> http://snaps.php.net/ ?
>> >Haven't had a chance to test this yet, but it's happened in every
>> >version from 4.0.4pl1 through to 4.0.6 so far...
>>
>> Please try the snapshot. There have been so many fixes and at least
>> two of them were module loading related.
>>
>> --Jani