Hello,
It seems that an important detail was missed in the RFC to deprecate
INTL_IDNA_VARIANT_2003 in PHP 7.2.0 (and later remove it). The only
other option available - INTL_IDNA_VARIANT_UTS46 - may not be
available at all, as PHP has ICU 4.0 as its minimum requirement, but
support for UTS#46 was introduced by ICU 4.6 ...
As a result, there may be systems where having a clean call to
idn_to_ascii(), idn_to_utf() is impossible.
I'm all for following deprecations by upstream, but I didn't find any
mention of this scenario in the discussions. I'm assuming nobody has
considered it and we're in a bit of a mess right now, so ...
My immediate thought is to simply bump the ICU version requirement,
but I have no idea what kind of an impact that would have.
[1] RFC: https://wiki.php.net/rfc/deprecate-and-remove-intl_idna_variant_2003
[2] ICU 4.6 release: http://site.icu-project.org/download/46
Cheers,
Andrey.
My immediate thought is to simply bump the ICU version requirement,
but I have no idea what kind of an impact that would have.
According to that page, 46 is seven years old. I for one am 100% okay
with making that the minimum, though not necessarily because of the
IDNA issue. If someone on a system running 46 needs to use the idn
functions with php 7.2, then they are motivated to bug their admin.
(Seriously though, who's on php 7.2, but hasn't updated ICU for that
long?)
(Seriously though, who's on php 7.2, but hasn't updated ICU for that
long?)
Probably nobody yet. The issue was uncovered in code that assumed the
constant was available on 5.4+, as noted in the manual, but it turned
out there's people on 5.6, 7.0 who don't have it.
2018-01-19 20:09 GMT+01:00 Andrey Andreev narf@devilix.net:
(Seriously though, who's on php 7.2, but hasn't updated ICU for that
long?)Probably nobody yet. The issue was uncovered in code that assumed the
constant was available on 5.4+, as noted in the manual, but it turned
out there's people on 5.6, 7.0 who don't have it.
Also PHP 7.1: https://github.com/zendframework/zend-validator/issues/193
We also had an issue report, but I can't find it currently, forgot to link
it from the commit:
https://github.com/amphp/uri/commit/2de94666447319d8695f2d11f3f005d5fee0876a
I think we only have to bump the minimum version once 7.4 is out, because
only 7.4 will change the default. You only get a deprecation notice now,
which is totally fine.
Regards, Niklas
Hi again,
I think we only have to bump the minimum version once 7.4 is out, because
only 7.4 will change the default. You only get a deprecation notice now,
which is totally fine.
I disagree that it's totally fine. I mean, it's technically fine (it
still works), but in principle it's not ok to have no option of
writing code that doesn't trigger warnings and notices. Certainly not
for the possible entirety of 7.2 and 7.3 life-cycles.
And yes, on one hand it's the server admins' fault, but all that does
is delegating to framework/library authors the responsibility to
explain the problem to clueless users. It's easy to explain that they
can't use feature X because they don't have Intl (which you can point
to on php.net), they should at least know what a PHP extension is.
Not so easy to explain they'll always get an E_DEPRECATED notice
because somebody set them up with a bad version of some acronym
they've never even had to know of.
Cheers,
Andrey.
It seems that an important detail was missed in the RFC to deprecate
INTL_IDNA_VARIANT_2003 in PHP 7.2.0 (and later remove it). The only
other option available - INTL_IDNA_VARIANT_UTS46 - may not be
available at all, as PHP has ICU 4.0 as its minimum requirement, but
support for UTS#46 was introduced by ICU 4.6 ...
As a result, there may be systems where having a clean call to
idn_to_ascii(), idn_to_utf() is impossible.I'm all for following deprecations by upstream, but I didn't find any
mention of this scenario in the discussions. I'm assuming nobody has
considered it and we're in a bit of a mess right now, so ...
Indeed, I had not considered this issue during the RFC process. Thanks
for bringing it up.
My immediate thought is to simply bump the ICU version requirement,
but I have no idea what kind of an impact that would have.
- ICU 4.0 has been released on 2008-07-02
- ICU 4.6 has been released on 2010-12-02
- ext/intl requires at least ICU 4.0 as of PHP 5.5.0 (released 2013-06-20)
Considering these release dates, it appears to be okay to require at
least ICU 4.6 as of PHP 7.2.2.
--
Christoph M. Becker