Hi Chris, I've just blogged about IDN support in PHP. This post include a (tiny) userland implementation of streams: http://dunglas.fr/2014/10/internationalized-domain-name-idn-and-php/
What do you think about the following to add native support : 1. As already stated, make ICU a dependency of core 2. Convert the host returned by php_parse_url here https://github.com/php/php-src/blob/master/ext/standard/http_fopen_wrapper.c#L154 to Punycode with http://icu-project.org/apiref/icu4c432/uidna_8h.html#a711fa1d2e6dd25d7368f5b3ea2aaedc6 It looks not so intrusive and relatively easy to implement. According to RFC I quote in the blog post, it should work with SSL too. I can make a PR (or a RFC if needed) with this method if it seems applicable. Best regards, 2014-09-24 8:33 GMT+02:00 Pierre Joye <pierre....@gmail.com>: > On Wed, Sep 24, 2014 at 2:48 AM, Stas Malyshev <smalys...@sugarcrm.com> > wrote: > > Hi! > > > >> I'll implement optional (and not default) support of IDN in > filter_var(). > >> > >> Does anyone known if it's better to use libIDN (LGPL) or ICU (custom > >> license deviated from the X license) from a license point of view? > > > > ICU is definitely better since we already have a lot of code using ICU > > and AFAIK our current IDN functions (idn_to_*) use ICU. Which means it > > would be advantageous to keep it in the single library - whatever bugs > > there may be, at least the user will be dealing with one set of bugs > > instead of two :) > > Indeed :) > > However I am not sure yet we should do it, or at least not by default. > It may introduce side effects or BC issues.While IDN is bi-directional > or could be called many times and returning the same result, we have > to be careful to do not break things out there, for example someone > relying on it to process URI/URL. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > -- Kévin Dunglas Consultant et développeur freelance http://dunglas.fr Tél. : 06 60 91 20 20
