Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1 ID: 64010 Comment by: andrebruce at gmail dot com Reported by:spam2 at rhsoft dot net Summary:htmlentities fundamentally broken in 5.4 Status: Not a bug Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.10 Block user comment: N Private report: N New Comment: Hello, I found this bug report searching for htmlentities broken I am seeing some broken applications like phppgadmin shipped with Ubuntu because of this change. Making it possible to change it globally on php.ini (or using the default_charset from php.ini) would be really interesting. Thanks. Previous Comments: [2013-09-02 18:05:25] spam2 at rhsoft dot net and again a broken backend on a production server running E_ALL reporting because the braindead idiot who made this change was not smart enugh to throw a *warning* if it returs an empty string while the input was not empty how stupid can developers act? [2013-01-17 18:41:04] spam2 at rhsoft dot net and last but not least WTF did whoever implemented the bullshit returning an emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that admins/developers which are running in E_ALL | E_STRICT since years smell if there something is still broken and need to get fixed? [2013-01-17 13:35:36] spam2 at rhsoft dot net and if you guys would be smart there would be an php.ini setting to specify the bahvior globally and/or per Directory instead hardcode incompatible changes breaking nearly ANY code written without wrappers [2013-01-17 13:33:21] spam2 at rhsoft dot net as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume that any input is UTF8 as default [2013-01-17 13:23:21] ras...@php.net If your page is ISO-8859-1 and you are using that as your internal encoding as well, then you need to specify that. Otherwise it leads to security issues. And since most people don't use ISO-8859-1 anymore, the safer default is to make sure we don't output invalid UTF-8 byte sequences when the developer has not specified the encoding. 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=64010 -- Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and again a broken backend on a production server running E_ALL reporting
because the braindead idiot who made this change was not smart enugh to throw a
*warning* if it returs an empty string while the input was not empty
how stupid can developers act?
Previous Comments:
[2013-01-17 18:41:04] spam2 at rhsoft dot net
and last but not least WTF did whoever implemented the bullshit returning an
emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that
admins/developers which are running in E_ALL | E_STRICT since years smell if
there something is still broken and need to get fixed?
[2013-01-17 13:35:36] spam2 at rhsoft dot net
and if you guys would be smart there would be an php.ini setting to specify the
bahvior globally and/or per Directory instead hardcode incompatible changes
breaking nearly ANY code written without wrappers
[2013-01-17 13:33:21] spam2 at rhsoft dot net
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
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=64010
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1 ID: 64010 Comment by: spam2 at rhsoft dot net Reported by:spam2 at rhsoft dot net Summary:htmlentities fundamentally broken in 5.4 Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.10 Block user comment: N Private report: N New Comment: WTF - why can i not submit a simple zip containing the spmale input base64_encoded in a seperate file because here you have only the option to attach patches Previous Comments: [2013-01-17 12:36:29] spam2 at rhsoft dot net Description: Like htmlspecialchars(), htmlentities() takes an optional third argument encoding which defines encoding used in conversion. If omitted, the default value for this argument is ISO-8859-1 in versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards and you broke randomly applications with this without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back [harry@rh:/downloads/htmlentities]$ ./test.php strlen($input): 4464 strlen(htmlentities($input, ENT_QUOTES)): 0 strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')): 6522 Test script: --- #!/usr/bin/php ?php $input = base64_decode(file_get_contents(__DIR__ . '/70acc70b9c93b6a677825241e8165562_base64.txt')); echo '' . \n; echo 'strlen($input):' . \n; echo strlen($input) . \n; echo '' . \n; echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n; echo strlen(htmlentities($input, ENT_QUOTES)) . \n; echo '' . \n; echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n; echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n; ? Expected result: NON-EMPTY reuturn value -- Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
Previous Comments:
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
[2013-01-17 12:36:29] spam2 at rhsoft dot net
Description:
Like htmlspecialchars(), htmlentities() takes an optional third
argument encoding which defines encoding used in conversion. If
omitted, the default value for this argument is ISO-8859-1 in
versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards
and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back
[harry@rh:/downloads/htmlentities]$ ./test.php
strlen($input):
4464
strlen(htmlentities($input, ENT_QUOTES)):
0
strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522
Test script:
---
#!/usr/bin/php
?php
$input = base64_decode(file_get_contents(__DIR__ .
'/70acc70b9c93b6a677825241e8165562_base64.txt'));
echo '' .
\n;
echo 'strlen($input):' . \n;
echo strlen($input) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES)) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n;
?
Expected result:
NON-EMPTY reuturn value
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
Previous Comments:
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
[2013-01-17 12:36:29] spam2 at rhsoft dot net
Description:
Like htmlspecialchars(), htmlentities() takes an optional third
argument encoding which defines encoding used in conversion. If
omitted, the default value for this argument is ISO-8859-1 in
versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards
and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back
[harry@rh:/downloads/htmlentities]$ ./test.php
strlen($input):
4464
strlen(htmlentities($input, ENT_QUOTES)):
0
strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522
Test script:
---
#!/usr/bin/php
?php
$input = base64_decode(file_get_contents(__DIR__ .
'/70acc70b9c93b6a677825241e8165562_base64.txt'));
echo '' .
\n;
echo 'strlen($input):' . \n;
echo strlen($input) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES)) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n;
?
Expected result:
NON-EMPTY reuturn value
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and if you guys would be smart there would be an php.ini setting to specify the
bahvior globally and/or per Directory instead hardcode incompatible changes
breaking nearly ANY code written without wrappers
Previous Comments:
[2013-01-17 13:33:21] spam2 at rhsoft dot net
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
[2013-01-17 12:36:29] spam2 at rhsoft dot net
Description:
Like htmlspecialchars(), htmlentities() takes an optional third
argument encoding which defines encoding used in conversion. If
omitted, the default value for this argument is ISO-8859-1 in
versions of PHP prior to 5.4.0, and UTF-8 from PHP 5.4.0 onwards
and you broke randomly applications with this
without specifiy 'ISO-8859-1' we get randomly EMPTY STRINGS back
[harry@rh:/downloads/htmlentities]$ ./test.php
strlen($input):
4464
strlen(htmlentities($input, ENT_QUOTES)):
0
strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')):
6522
Test script:
---
#!/usr/bin/php
?php
$input = base64_decode(file_get_contents(__DIR__ .
'/70acc70b9c93b6a677825241e8165562_base64.txt'));
echo '' .
\n;
echo 'strlen($input):' . \n;
echo strlen($input) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES)):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES)) . \n;
echo '' .
\n;
echo 'strlen(htmlentities($input, ENT_QUOTES, \'ISO-8859-1\')):' . \n;
echo strlen(htmlentities($input, ENT_QUOTES, 'ISO-8859-1')) . \n;
?
Expected result:
NON-EMPTY reuturn value
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
Bug #64010 [Com]: htmlentities fundamentally broken in 5.4
Edit report at https://bugs.php.net/bug.php?id=64010edit=1
ID: 64010
Comment by: spam2 at rhsoft dot net
Reported by:spam2 at rhsoft dot net
Summary:htmlentities fundamentally broken in 5.4
Status: Not a bug
Type: Bug
Package:Scripting Engine problem
Operating System: Linux
PHP Version:5.4.10
Block user comment: N
Private report: N
New Comment:
and last but not least WTF did whoever implemented the bullshit returning an
emptry string WITHOUT THROW A WARNING AT LEAST - who do you guys imagine that
admins/developers which are running in E_ALL | E_STRICT since years smell if
there something is still broken and need to get fixed?
Previous Comments:
[2013-01-17 13:35:36] spam2 at rhsoft dot net
and if you guys would be smart there would be an php.ini setting to specify the
bahvior globally and/or per Directory instead hardcode incompatible changes
breaking nearly ANY code written without wrappers
[2013-01-17 13:33:21] spam2 at rhsoft dot net
as long as PHP at whole is NOT really capable UTF8 it is bullshit to assume
that any input is UTF8 as default
[2013-01-17 13:23:21] ras...@php.net
If your page is ISO-8859-1 and you are using that as your internal encoding as
well, then you need to specify that. Otherwise it leads to security issues. And
since most people don't use ISO-8859-1 anymore, the safer default is to make
sure
we don't output invalid UTF-8 byte sequences when the developer has not
specified
the encoding.
[2013-01-17 13:08:28] spam2 at rhsoft dot net
and NO it is not a smart idea to change the complete default behavior
it is bullshit, if your page is ISO-8859-1 and you do htmlentities('üöä') it
is fundamentally broken to return empty strings in a random number of funtions
[2013-01-17 12:40:25] spam2 at rhsoft dot net
WTF - why can i not submit a simple zip containing the spmale input
base64_encoded in a seperate file because here you have only the
option to attach patches
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=64010
--
Edit this bug report at https://bugs.php.net/bug.php?id=64010edit=1
