This is the new behaviour with the cli version of PHP.
If this is happening for cgi or apache, reopen this
report.

Ok, so this is changed from Open to Bogus because what? You make a change that isn't documented?

This behavior IS with the Apache server. It is a PHP page served up by Apache.

It was labelled bogus because of the assumption that you are incorrectly using the CLI version of PHP where this is now default.  As was stated, if you are indeed using the Apache module version or the CGI version, you could re-open.  You didn't specify this when you re-opened, just that you were using Apache.  Look at the output and tell us what it says next to "Server API".

Here. Hope this helps.

System => Linux www 2.4.18 #1 Thu Jun 13 15:04:26 EDT 2002 i686
Build Date => Sep 10 2002 10:37:38
Configure Command =>  './configure' '--prefix=/usr' '--enable-dba=shared' '--with-mm' '--enable-dbg=shared' '--enable-dbg-profiler' '--enable-force-cgi-redirect' '--enable-magic-quotes' '--enable-calendar' '--enable-cli' '--enable-bcmath' '--enable-dba' '--enable-dio' '--enable-ftp' '--enable-libgcc' '--enable-mailparse' '--enable-mbstring' '--enable-sockets' '--enable-wddx' '--enable-trans-sid' '--enable-xml' '--enable-dbx' '--enable-exif' '--enable-track-vars' '--enable-sigchild' '--enable-static' '--enable-shared' '--with-mysql=/usr' '--enable-sysvsem' '--enable-sysvshm' '--enable-ftp' '--enable-sockets' '--enable-inline-optimization' '--with-openssl=/usr/local/ssl' '--with-fdftk=/usr' '--with-ldap' '--with-ming' '--with-mcal=../../libmcal' '--with-gettext' '--with-xml' '--with-imagick' '--with-yaz' '--with-pear' '--with-zlib' '--with-dom' '--with-bz2' '--with-gdbm' '--with-gmp' '--with-curl' '--with-t1lib' '--with-msession=/usr/src/otai/phoenix' '--with-ldap' '--with-regex=php' '--with-mhash' '--with-iconv=/usr/lib' '--with-java=/opt/j2sdk1.4.0_01' '--with-oci8=/usr/oracle/OraHome1' '--with-oracle=/usr/oracle/OraHome1' '--with-xmlrpc' '--with-pdflib=/usr' '--with-apxs2=/usr/apache/bin/apxs'
Server API => Apache 2.0 Filter
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/lib/php.ini
API Versions: => PHP: 20020307
PHP Extension: 20020429
Zend Extension: 20020903
Debug Build => no
Thread Safety => disabled
Registered PHP Streams => php, http, ftp, https, ftps, compress.bzip2, compress.zlib

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Turn on html_errors in php.ini. This was recently changed to allow the CLI and CGI modules to have a pretty phpinfo() too.

Derick

I have checked the manual. I see no place where this change in behavior of phpinfo() is documented, except in the NEWS section of the source code where the implication is that it was changed for the CLI but not the Apache module version.

I am happy to be corrected but considering that the large amount of preprinted PHP installation guides refers to this use of phpinfo() to test an installation, this is not exactly a subtle behavior change.

Regards.

There is no behavioural change for standard installs.  The default setting for html_errors is on, so only people who specifically changed their php.ini file to turn off html tags around their error messages will have html tags stripped from their phpinfo() output as well.

Unfortunately,  this (html_errors) default setting of "On" is described in ini_set() but not in the documentation for the configuration file. Moreover, the TWO distributed php.ini- files both have html_errors = Off commented out. One implication is that uncommenting this would CHANGE the behavior however, I have also seen this format used to indicate defaults. 

But I guess my point is that the phpinfo() documentation has not been changed to reflect the behavior when used as an Apache 2 module. In particular, the function documentation does not indicate that the behavior of the function is modified by the value for html_errors in the php.ini file.

Of course it hasn't, you are using a CVS version from today.  If you were using a released version you might have a case for complaining, but you aren't.

I'm not complaining about the CVS. My beef was with the response that, first, this is bogus when, in fact, it isn't documented behavior and, second, "read the manual" when it isn't in the manual.

To me it seems reasonable to believe that an undocumented change in behavior in the CVS could be a "bug". A simple response to this would have been the SECOND paragraph of Derick's posting (the first, suggesting that this behavior is in the manual is, itself, bogus).

So, a lot of silly bandwidth has been wasted when a two sentence response would have sufficed. Thanks.

But our response was a single sentence.
This code is only a few days old as you yourself said,
and the exact nature of this change is still being discussed on php-dev.
Of course we haven't documented it yet :-)