php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #76184 string beginning with < error
Submitted: 2018-04-04 16:39 UTC Modified: 2018-04-05 06:36 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: jalesmonteiro at hotmail dot com Assigned: cmb (profile)
Status: Not a bug Package: Strings related
PHP Version: 7.1.16 OS: UBUNTU 17.10
Private report: No CVE-ID: None
 [2018-04-04 16:39 UTC] jalesmonteiro at hotmail dot com
Description:
------------
Strings beginning with the '<' char can't be printed.
The functions strlen and ctype_print show the return the expected, however the echo and print shows nothing.

Test script:
---------------
<?php

$str = '<Hello>';

echo strlen($str);
echo '<br/>';

echo ctype_print($str);
echo '<br/>';

foreach (count_chars($str, 1) as $i => $val) {
	echo 'There were '.$val.' instance(s) of "' , chr($i) , '" in the string.';
	echo '<br/>';
}

echo $str;
?>

Expected result:
----------------
7
1
There were 1 instance(s) of "<" in the string.
There were 1 instance(s) of ">" in the string.
There were 1 instance(s) of "H" in the string.
There were 1 instance(s) of "e" in the string.
There were 2 instance(s) of "l" in the string.
There were 1 instance(s) of "o" in the string.
<Hello>

Actual result:
--------------
7
1
There were 1 instance(s) of "<" in the string.
There were 1 instance(s) of ">" in the string.
There were 1 instance(s) of "H" in the string.
There were 1 instance(s) of "e" in the string.
There were 2 instance(s) of "l" in the string.
There were 1 instance(s) of "o" in the string.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-04-04 16:44 UTC] spam2 at rhsoft dot net
nonsense - they are printed and you wrote perfect sample code how not to do it open for injection by not care about special chars - look at the source code of the page and you see them

RTFM of basic HTML and use http://php.net/manual/en/function.htmlentities.php

if you come up with something like "Strings beginning with the '<' char can't be printed" first run your script in a terminal and then spend 2 seconds what the output means for a HTML renderer
 [2018-04-04 16:44 UTC] jalesmonteiro at hotmail dot com
the function count_chars also return the expected.
 [2018-04-04 16:46 UTC] spam2 at rhsoft dot net
> the function count_chars also return the expected

the output too, open the damned source of the website in yur browser and you see
 [2018-04-04 19:47 UTC] spam2 at rhsoft dot net
> "rhsoft" continues their aggressive behaviour on the bug 
> tracker still too. One recent illustration is
> https://bugs.php.net/bug.php?id=76184&edit=1

what exactly is aggressive here?

"Strings beginning with the '<' char can't be printed" is simply not true, can be easily proven by run the "sample code" within a shell or just right click in Firefox and select "show page source" 

the fact that such strings needs to be properly handeled with htmlentities() is security relevant as we have enough code in the wild with not the sligtest thoughs about security
 [2018-04-04 21:25 UTC] cmb@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: cmb
 [2018-04-04 21:25 UTC] cmb@php.net
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

As has been said, if you generate HTML, you have to escape special
HTML characters; otherwise the browser may interpret (parts of)
the string as HTML tags (in this case <Hello>).

> as we have enough code in the wild with not the sligtest thoughs
> about security

ACK.  There is still no need to use explicit language. :)
 [2018-04-04 21:34 UTC] rowan dot collins at gmail dot com
@rhsoft: Being aggressive and being right aren't mutually exclusive.

@jalesmonteiro: I apologise on behalf of the community for the tone used in previous comments; you did nothing to deserve such strong language. However, it is true that this is a mistake on your part rather than a bug in PHP: the < and > signs are displayed by PHP, but are being hidden by your browser, which interprets anything between those symbols as an HTML tag, even if it has no meaning in a current version of HTML. You can check this by selecting "view source" or "inspect element" in your browser. If your whole page of content is actually pain text, you could tell the browser this using header('Content-Type: text/plain'); more likely, you want to display some text within an HTML page, in which case you can escape it using htmlspecialchars() or html_entities(). Search on http://php.net for documentation and examples of all your functions, and happy programming. :)
 [2018-04-04 21:44 UTC] spam2 at rhsoft dot net
> ACK.  There is still no need to use explicit language. :)

in fact the opposite is true - *because* nobody out there the past years is using exlicit language for anything instead of empty phrases most of the problems in the IT industry exists - be nice and don't say anything, use a lot of hearwarming words and hide the information between them - sorry - but i prefer the Torvalds style

at least the "the function count_chars also return the expected" should noit have happended at all if you mean "the output too, open the damned source of the website in yur browser and you see" with "explicit language"
 [2018-04-04 23:04 UTC] slevy1 at pipeline dot com
Whether this is or is not a bug may be debatable.  Thank you to the OP for raising this issue -- you've given me something to think about!  In any event, the code does work outside of a browser context, i.e. on the command line which produced this result:

<hello>
Anything to see above this line?

When I ran this script:

<?php
$str = '<hello>';
echo $str,"\n";
echo "Anything to see above this line?";

In order for the script to work as you'd wish, you may use htmlentities() as follows:

<?php

$str = htmlentities('<hello>');
echo $str,"\n";
echo "Anything to see above this line?";

The reason is as others have stated that the characters '<' and '>' hold special meaning in the browser.  

The fact that the behavior is not identical given the web browser vs. the command line does appear to be an inconsistency but sometimes that's life and we just need to live with it.  Or, do we?   Maybe this point merits more discussion before hastily closing and dismissing this report as "No Bug".
 [2018-04-04 23:19 UTC] spam2 at rhsoft dot net
> The fact that the behavior is not identical given 
> the web browser vs. the command line does appear 
> to be an inconsistency but sometimes that's life 
> and we just need to live with it.  Or, do we?   
> Maybe this point merits more discussion before 
> hastily closing and dismissing this report

seriously?

<Hello> for a CLI output is just a string, taht's it
<Hello> for a HMTL browser is a invalid tagm but still a tag

<Hello> for a browser when you send header('Content-Type: text/plain'); before is the ame behavior as for a CLI script - but when you send the browser a html content-type (which is default for non-cli) it's a tag and is not displayed linke <strong> or <h1> or whatever

<Hello>Test</Hello> would display "Test" and a html-validator would complain about the unknown tag - that's it
 [2018-04-05 06:36 UTC] stas@php.net
> but i prefer the Torvalds style

Please remember you are not Linus Torvalds. When you invent next Linux and and next git, we can come back to this discussion, but before that, please use style that is more polite. Nobody asks you to hide information, but the information can be delivered in polite, or, if you can not master that, neutral tone. There's no information that can not be conveyed without swearing and rudeness. It just requires some self-control and effort, and I think that's what would be nice to happen here.
 [2018-04-22 02:00 UTC] a at b dot c dot de
> The fact that the behavior is not identical given the web browser
> vs. the command line does appear to be an inconsistency but
> sometimes that's life and we just need to live with it.  Or, do we?
> Maybe this point merits more discussion before hastily closing and
> dismissing this report as "No Bug".

There is no inconsistency. PHP is sending (almost, see next paragraph)
the same output in both cases, but the programs receiving that output
are handling it differently. But that is entirely up to how the
receiving program interprets the output, it's not PHP's
responsibility. The CLI maps bytes to characters according to whatever
character encoding it is set to; the web browser parses it as an HTTP
response containing an HTML document, with all of their rules about
headers and how to interpret characters like '<' and '>'. This is why
browsers have had a "view source" option since the very earliest days
of the web (right back to NCSA Mosaic) - not to mention all the other
debugging tools they've picked up since: because what you see when the
page is rendered is not exactly what the browser received.

If there is any inconsistency between the CLI and web server
interfaces, it's that the former does not include HTTP headers at the
start of its output (because the terminal would have no use for them*
and would just print them like anything else it receives, probably
messing up whatever workflow the CLI script was being used for). If
you want consistency there, you'd have to stop the web interfaces from
automatically adding headers; write all your scripts to include lines
like "header("HTTP/1.0 200 OK"); header('Content-type: text/html');"
and so forth.

(*I have used Telnet as a web client - typing HTTP requests by hand
  and separating out the headers from the body myself. So it's
  _possible_ for a terminal to use a web interface - but that's just a
  consequence of the common protocol infrastructure that makes the
  Internet. It's not a reason for Telnet to start parsing HTML tags, or
  for a web browser to stop doing so.)
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 05:01:28 2024 UTC