php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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 Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: kyrian at ore dot org
New email:
PHP Version: OS:

 

 [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

Pull Requests

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: Sun Dec 22 06:01:30 2024 UTC