ID: 20310
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Won\'t fix
-Bug Type: Variables related
+Bug Type: Feature/Change Request
Operating System: SunOS
PHP Version: 4.2.2
New Comment:
Look - it's really simple:
<?php
function ob_smart_html_handler($string)
{
$string = (isset($_SERVER['REMOTE_ADDR'])) ?
htmlspecialchars($string) : $string;
return $string;
}
// create $var here
ob_start('ob_smart_html_handler');
print_r($var);
ob_end_flush();
?>
Additionally, using 4.3.0 (slightly different output):
<?php
print(htmlspecialchars(var_export($var, TRUE)));
?>
Now - those few lines of 'extra' code, simply don't warrant a change in
behavior, that has the potential to break CLI code.
Previous Comments:
------------------------------------------------------------------------
[2002-11-08 09:24:59] [EMAIL PROTECTED]
Enclosing print_r with <pre> and </pre> does not help!
This is exactly what I demonstrate in
<http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.php>.
I was not aware that PHP can also be used without a HTML
context; so I am not sure what to suggest. Could print_r
determine whether it is writing to a HTML source and act accordingly?
In any case, as it stands currently, print_r is akin to
a time-bomb in unsuspecting authors' HTML pages.
------------------------------------------------------------------------
[2002-11-08 08:48:16] [EMAIL PROTECTED]
Just a quick comment on this (and why I think it should stay as it
is):
I use print_r both in online (Web-based) and offline scripting.
Changing print_r to output html characters would screw things up for
those people that use PHP for more than just a web language.
That being said, if you want to use the debugging tool, just use
<PRE></PRE> around the print_r if you need to view it
correctly. Nothing's wrong with the "tool" as it works now.
------------------------------------------------------------------------
[2002-11-08 08:36:21] [EMAIL PROTECTED]
Just because print_r is a debuggung tool,
it shold not introduce additional bugs into the HTML code!
But as it is, it will
- insert a HTML tag whenever it should report
a less-than csign,
- insert a HTML entity whenever it should report
an ampersand sign,
- spoil the whole HTML syntax, whenever it simply
should report a double-quote sign.
This renders print_r rather a dangerous (if not
to say: unusable) tool.
Please revert the status of Bug #20310 to open,
or perhaps to feature-request.
------------------------------------------------------------------------
[2002-11-08 08:16:28] [EMAIL PROTECTED]
print_r is just a debugging tool, I see no reason to have
htmlspecialchars applied to it. Also, you can do this yourself quite
easily by using output buffers if you _really_ need this.
Derick
------------------------------------------------------------------------
[2002-11-08 08:01:37] [EMAIL PROTECTED]
print_r writes directly to php://output, hence
its output should comply with HTML syntax rules.
However, print_r will issue non-compliant code,
or generate spurious entities, whenever a
variable contains an HTML special character.
Hence, print_r should apply htmlspecialchars to
all strings it is going to write to php://output.
Try the demo at
<http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.php>
with Netscape 6, or Opera 6, as IE 6 will not reveal
all the surprises I've hidden therein ;-)
The pertinent PHP source can be seen at
<http://www.rz.uni-konstanz.de/Antivirus/tests/print_r.txt>.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=20310&edit=1
