php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13176 Headers output in HTML body.
Submitted: 2001-09-06 11:16 UTC Modified: 2001-10-28 10:35 UTC
From: kyrian at ore dot org Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 4.0.6 OS: RedHat Linux 6.0(ish)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
30 - 5 = ?
Subscribe to this entry?

 
 [2001-09-06 11:16 UTC] kyrian at ore dot org
Hi,

Sorry if this is a duplicate (I've checked and it doesn't look like it though), or me being silly...

We've had this problem in versions 4.0.4pl1 through to PHP4.0.6, running as a CGI through apache (various versions between 1.3.3 and 1.3.12 I think...) using the setup described in the PHP docs.

Configure options approximately (they have changed through various versions of PHP I've compiled up)

./configure --with-mysql --with-gd --enable-force-cgi-redirect --with-config-file-path=/etc/php4/cgi/ --with-imap --enable-ftp --with-openssl --with-kerberos=/usr/kerberos --with-zlib-dir=/usr/lib --with-jpeg=/usr --with-tiff=/usr

The systems that PHP are running on are some 20 patched-up RH6.0 machines, all of which exhibit this symptom.

It can be got around by disabling loading of any dynamic modules, even dynamic modules which don't exist on the server cause this problem if you attempt to load them with an "extension=" line in the relevant php.ini.

I'd previously assumed it to be specific to the mysql module or similar, but it seems that it's the module loading routine which is erroneously outputting a newline or two to indicate the end of the HTTP headers before it should do, because if you try to load a module that doesn't exist it still does the same.

I'm reporting it now because I have just got a new bit of information, and nobody could have reported it yet otherwise I assume you would have solved it in php-4.0.5.

Yours,

Kev.

PS. Some system info. Just ask if you need more that this...

Linux version 2.2.13 (root@webcache.netbenefit.co.uk) (gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)) #1 SMP Mon Dec 13 01:50:21 GMT 1999

Red Hat Linux release 6.0 (Hedwig)

Server version: Apache/1.3.9 (Unix)
Server built:   Dec 13 1999 17:18:12

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-09-06 11:47 UTC] sniper@php.net
Does this happen with certain script?
Do you use ob_* functions?
Is output_buffering on/off in your php.ini?
Is output_handler set in your php.ini?
Is zlib.output_compression set in your php.ini?
Does this happen with latest CVS snapshot from
http://snaps.php.net/ ?

--Jani

 [2001-10-02 19:38 UTC] sniper@php.net
No feedback.
 [2001-10-03 18:01 UTC] sniper@php.net
user feedback (he didn't set the password for this report):
-----------------------------------------------------------

I've just done a compile and test of the latest snapshot of 
PHP from http://snaps.php.net/

Config:

./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 

Archive: php4-200110030000

Without lines loading extensions in php.ini, it's okay, but 
with one loading mysql.so, I get:

X-Powered-By: PHP/4.0.8-dev
Content-type: text/html

In the HTML, rather than as headers.

Looks like something's outputting a "\n" before sending 
those headers.

Using headers_sent() reports that they have not been sent at 
the very start of php code which illustrates this problem, 
as you might expect. So it's probably something in the 
header sending/preparation routines being silly...

Also, it occurs to me that perhaps this bug is caused by 
trying to load a module in that's already compiled into the 
main php executable (we run it in CGI mode, btw...)

 [2001-10-28 10:35 UTC] sniper@php.net
Bogusing this report. Asked the user to submit new report
with a proper password. (This one had empty passwd)

--Jani

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 11:01:27 2024 UTC