Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77334 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 81189 invoked from network); 19 Sep 2014 10:28:44 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Sep 2014 10:28:44 -0000 Authentication-Results: pb1.pair.com header.from=are.you.winning@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=are.you.winning@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.41 as permitted sender) X-PHP-List-Original-Sender: are.you.winning@gmail.com X-Host-Fingerprint: 209.85.216.41 mail-qa0-f41.google.com Received: from [209.85.216.41] ([209.85.216.41:38554] helo=mail-qa0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AE/37-44461-B550C145 for ; Fri, 19 Sep 2014 06:28:44 -0400 Received: by mail-qa0-f41.google.com with SMTP id f12so2470186qad.28 for ; Fri, 19 Sep 2014 03:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=bj52qDQ76F1XcmP8NSm/XctffFmS/tKhPRTGYUY5U/c=; b=V9nQEO7s2KZUCJ9Emc99eHi6eXtSP/tdNwxOd/+R4Yqm5hGtt6irEzdtNkCFvjLGjC BvxgvUIcIGI2KMr0MVTZiQGz/eZJpv5zjV/4mYryy3+IIoXb9l6vMDb8QkoMmN3J9oRC /svDlKQNObYTs6FMwQdvPUEW60uDtJU8OiDHVPHTxLLKm3sU2jG+yy75PcvmXYnw9cUJ 13V37OAN8hBXciWXhyLhRvQyywP9yif2IBxgsx+m6bhX4P8WEqkcLYbw5uQbgKXvjCbF FpxVTO8CIjco1UUdtpB9P2Pwkmwir/AnLuxJjFppKTsPJjqHLE3pG7D+24pzFafpqiWK O+vw== MIME-Version: 1.0 X-Received: by 10.140.82.85 with SMTP id g79mr2674218qgd.14.1411122521487; Fri, 19 Sep 2014 03:28:41 -0700 (PDT) Sender: are.you.winning@gmail.com Received: by 10.141.28.193 with HTTP; Fri, 19 Sep 2014 03:28:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Sep 2014 11:28:41 +0100 X-Google-Sender-Auth: buNmUDEVOyxsl8ACZ4KwybL4fEA Message-ID: To: Pierre Joye Cc: Chris Wright , PHP internals , =?UTF-8?Q?K=C3=A9vin_Dunglas?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Internationalized Domain Name support in FILTER_VALIDATE_URL From: cw@daverandom.com (Chris Wright) On 19 September 2014 10:58, Pierre Joye wrote: > Hi, > > On Sep 19, 2014 4:03 PM, "Chris Wright" wrote: >> >> K=C3=A9vin >> >> On 18 September 2014 21:26, K=C3=A9vin Dunglas wrote= : >> > Hello, >> > >> > I'm working on enhancing the FILTER_VALIDATE_URL filter ( >> > https://github.com/php/php-src/pull/826). >> > The current implementation does not support validation of >> > internationalized >> > domain names (i.e: http://www.acad=C3=A9mie-fran=C3=A7aise.fr/ >> > ). >> > >> > Support of IDN validation can be easily added using ICU's >> > uidna_toASCII() >> > function. >> > >> > Is it acceptable to add a dependency to ICU for ext/filter? >> > Another option is to add a HAVE_ICU constant in main/php_config.h and = to >> > validate IDN only if ICU is present. >> > >> > What strategy is preferred? >> >> I've done some work around this area previously, and all I will say >> is: be careful with what you do with this from a userland PoV. >> >> PHP does not natively support IDN in stream open routines or SSL >> verification routines. It will never support these things without at >> least one of: >> - a core dependency on ICU, libidn or similar >> - moving streams into an extension so a dependency can be introduced >> there (probably not sanely possible) >> - an in-house NAMEPREP implementation (this is the hard part of IDN, >> punycode itself is pretty trivial to implement once you have a >> canonical set of codepoints) >> >> These things can be implemented with *a lot* of boilerplate in >> userland when you have ext/intl, but it's not pretty. libcurl *can* >> support IDN if it was built against libidn, I'm not sure if this is >> currently the case in common distributions or not. Since one almost >> never just validates a URL string, it's usually a precursor to >> attempting to open it, this could lead to some pretty hefty wtfs. >> >> In short, while I'm generally for ext/filter being able to handle IDN, >> I *do not* believe it should do it implicitly, it should require an >> explicit flag, because it will break *a lot* of code if IDN is >> suddenly treated as valid where it previously wasn't. > > I am really not sure about that especially the enabling by default part. > > The doc is pretty clear about what this filter supports and allowing idn = may > break a lot of codes out there. > > From an implementation point of view we may not need ICU to support IDN. > Windows does not use it and there are license friendly decoder > implementations too. If we can agree on adding a core dependency on , I already have an experimental local branch that adds full IDN support to streams. It's based on libidn but it would be easy enough to swap it out for something else that provides the same functionality. In my (biased) opinion, streams are a far more important element of IDN support. Filter validation is just polish/a nicety on top.