Edit report at https://bugs.php.net/bug.php?id=76184&edit=1
ID: 76184
Comment by: a at b dot c dot de
Reported by: jalesmonteiro at hotmail dot com
Summary: string beginning with < error
Status: Not a bug
Type: Bug
Package: Strings related
Operating System: UBUNTU 17.10
PHP Version: 7.1.16
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
> 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.)
Previous Comments:
------------------------------------------------------------------------
[2018-04-05 06:36:38] 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-04 23:19:24] 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-04 23:04:16] 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 21:44:17] 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 21:34:53] 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. :)
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=76184
--
Edit this bug report at https://bugs.php.net/bug.php?id=76184&edit=1