php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #74276 idn_to_ascii() empty
Submitted: 2017-03-20 07:55 UTC Modified: 2021-11-11 11:18 UTC
Votes:6
Avg. Score:4.2 ± 0.9
Reproduced:5 of 5 (100.0%)
Same Version:3 (60.0%)
Same OS:3 (60.0%)
From: dsk at topaz dot damianek dot be Assigned:
Status: Open Package: I18N and L10N related
PHP Version: 5.6.30 OS: FreeBSD 11
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dsk at topaz dot damianek dot be
New email:
PHP Version: OS:

 

 [2017-03-20 07:55 UTC] dsk at topaz dot damianek dot be
Description:
------------
FreeBSD port has ICU compilled '--with-data-packaging=archive' option - intl
extension accept this durning compillation.
In mine environment php works as fpm with chroot, like
/home/username/domainname.tld/ where is public_html
as documentroot for webserver.
Inside chroot is also roundcube webmail.
Roundcube uses idn_to_ascii() function to determine $username and
$domain_part - but idn_to_ascii() don't work, eg.  idn_to_ascii($username)
is empty, idn_to_ascii($domain_part) also is empty without any
info/error/message.
From roundcube team:
"Looks like a PHP level issue. From intl extension we use idn_to_ascii()
 function. I guess it returns empty string instead of a properly converted 
string or sth."

Test script:
---------------
From roundcube file 'program/include/rcmail.php'

// Here we need IDNA ASCII
// Only rcube_contacts class is using domain names in Unicode
$host     = rcube_utils::idn_to_ascii($host);
$username = rcube_utils::idn_to_ascii($username);


Expected result:
----------------
If idn_to_ascii() is empty, show or save in errorlog some E_NOTICE or
similar.



Patches

android11-qpr1-c-release.json (last revision 2021-07-18 13:44 UTC by damianss640 at gmail dot com)
Hello (last revision 2017-03-20 13:26 UTC by test123 at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2017-03-20 08:10 UTC] requinix@php.net
-Status: Open +Status: Feedback -Type: Feature/Change Request +Type: Bug -Package: *Unicode Issues +Package: intl
 [2017-03-20 08:10 UTC] requinix@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

What are the values of $host and/or $username being passed to idn_to_ascii()? The output from var_dump() and bin2hex() would be helpful. Are the strings in UTF-8?

And is this behavior present in a version of PHP still in active support? That's PHP 7.0 or 7.1.
 [2017-03-20 08:42 UTC] dsk at topaz dot damianek dot be
-Status: Feedback +Status: Open
 [2017-03-20 08:42 UTC] dsk at topaz dot damianek dot be
Proper script example from http://php.net/manual/en/function.idn-to-ascii.php
<?php
echo idn_to_ascii('täst.de'); 
?>

When ICU is compilled '--with-data-packaging=archive' idn_to_ascii()
(php fpm chrooted to /home/username/example.tld/documentroot)
from that example will not return 'xn--tst-qla.de' - will be empty.

Also more simple test:
<?php
echo idn_to_ascii('google.com'); 
?>

In chrooted php-fpm with ICU '--with-data-packaging=archive'
idn_to_ascii also will be empty.

Values of $host and $username passed to idn_to_ascii() is correct,
and are not UTF-8 - eg. dsk@topaz.damianek.be, $username = dsk,
$host = topaz.damianek.be.

On PHP 7.0 or PHP 7.1 not tested yet.
 [2017-08-30 13:08 UTC] matpockuh at gmail dot com
/usr/local/share/icu should be mounted into chrooted environment to make idn_to_ascii() working
 [2017-08-30 16:00 UTC] matpockuh at gmail dot com
But I agree with "If idn_to_ascii() is empty, show or save in errorlog some E_NOTICE or similar"
It's too hard to find the problematic function without any error/notice messages.
 [2018-01-10 20:25 UTC] shalom at starltd dot net
Hello
also for php7.1.13
I try to use:
echo idn_to_ascii('täst.de'); 
and it's work and show: xn--tst-qla.de
but, when I try to use:
echo idn_to_ascii('בדיקה123.co.il'); 

it's show empty blank page, no error and no value

Regards
 [2018-05-12 18:37 UTC] ab@php.net
-Type: Bug +Type: Documentation Problem
 [2018-05-12 18:37 UTC] ab@php.net
The described situation sounds barely as a PHP issue. With the given ICU configuration, any chroot'ing program would have an issue. PHP is also available with other SAPIs like Apache module, etc. that don't require chroot'ing. The suggestion to extra mount data directory is plausible. The check for an erroneous function output needs to be done in the application, adding a check in a single function for an unusual use case is IMO an overkill. Changing the type to the documentation issue therefore.

@shalom at starltd dot net, your issue seems to be ICU data and version dependent and thus not related to this ticket.

Thanks
 [2021-07-18 13:44 UTC] damianss640 at gmail dot com
The following patch has been added/updated:

Patch Name: android11-qpr1-c-release.json
Revision:   1626615847
URL:        https://bugs.php.net/patch-display.php?bug=74276&patch=android11-qpr1-c-release.json&revision=1626615847
 [2021-11-11 11:18 UTC] nikic@php.net
-Package: intl +Package: I18N and L10N related
 [2023-01-02 12:24 UTC] samira dot akhlaqi314 at gmail dot com
Thanks for sharing. I found a lot of interesting information here.


(https://www.wyndhamrewards.me/)php.net
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 18 23:01:27 2024 UTC