from:"Otto . Stolz"

#20310 [Com]: print_r should apply htmlspecialchars

2002-11-11 Thread Otto . Stolz

 ID:   20310
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Won\'t fix
 Bug Type: Feature/Change Request
 Operating System: SunOS
 PHP Version:  4.2.2
 New Comment:

Thank you for those hints.
As said before, I was not aware that existing CLI code
might be broken by my request.


Previous Comments:


[2002-11-08 13:47:02] [EMAIL PROTECTED]

Look - it's really simple:


Additionally, using 4.3.0 (slightly different output):


Now - those few lines of 'extra' code, simply don't warrant a change in
behavior, that has the potential to break CLI code.



[2002-11-08 09:24:59] [EMAIL PROTECTED]

Enclosing print_r with  and  does not help!
This is exactly what I demonstrate in
.

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



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20310

-- 
Edit this bug report at http://bugs.php.net/?id=20310&edit=1

#20310 [Com]: print_r should apply htmlspecialchars

2002-11-08 Thread Otto . Stolz

 ID:   20310
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Won\'t fix
 Bug Type: Variables related
 Operating System: SunOS
 PHP Version:  4.2.2
 New Comment:

Enclosing print_r with  and  does not help!
This is exactly what I demonstrate in
.

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.


Previous Comments:


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




-- 
Edit this bug report at http://bugs.php.net/?id=20310&edit=1

#20310 [Com]: print_r should apply htmlspecialchars

2002-11-08 Thread Otto . Stolz

 ID:   20310
 Comment by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Won\'t fix
 Bug Type: Variables related
 Operating System: SunOS
 PHP Version:  4.2.2
 New Comment:

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.


Previous Comments:


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




-- 
Edit this bug report at http://bugs.php.net/?id=20310&edit=1

#20310 [NEW]: print_r should apply htmlspecialchars

2002-11-08 Thread Otto . Stolz

From: [EMAIL PROTECTED]
Operating system: SunOS
PHP version:  4.2.2
PHP Bug Type: Variables related
Bug description:  print_r should apply htmlspecialchars

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
 
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
.
-- 
Edit bug report at http://bugs.php.net/?id=20310&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20310&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20310&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20310&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20310&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20310&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20310&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20310&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20310&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20310&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20310&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20310&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20310&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20310&r=isapi

#20308 [NEW]: parse_url does not understand the Mailto scheme

2002-11-08 Thread Otto . Stolz

From: [EMAIL PROTECTED]
Operating system: SunOS
PHP version:  4.2.2
PHP Bug Type: URL related
Bug description:  parse_url does not understand the Mailto scheme

parse_url('mailto:Otto.Stolz@;uni-konstanz.de')
yields:
 array( ['scheme'] => 'mailto'
['path'] => '[EMAIL PROTECTED]'
  )

According
to 
and ,
it should rather yield:
 array( ['scheme'] => 'mailto'
['host'] => 'uni-konstanz.de'
['user'] => 'Otto.Stolz'
  )

A test page can be found at
,
the pertinent PHP source at
.
-- 
Edit bug report at http://bugs.php.net/?id=20308&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20308&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20308&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20308&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20308&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20308&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20308&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20308&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20308&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20308&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20308&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20308&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20308&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20308&r=isapi

#20310 [Com]: print_r should apply htmlspecialchars

#20310 [Com]: print_r should apply htmlspecialchars

#20310 [Com]: print_r should apply htmlspecialchars

#20310 [NEW]: print_r should apply htmlspecialchars

#20308 [NEW]: parse_url does not understand the Mailto scheme

5 matches

Site Navigation

Mail list logo

Footer information