On 2020/06/07 16:18, f.holop wrote: > Stuart Henderson - Fri, 05 June 2020 at 00:03:04 > > Adding it would add more code to something that is quite a common > > dependency. Maybe it's useful enough to be worth it (being from a > > country with mostly 7-bit charset I don't get much of a vote in this ;) > > but along with the upside of support IDNs, there is a downside to > > pulling in (historically a bit buggy) code to all ports using the > > library. > > I agree, it is marginally useful... Is that margin worth it? > > In my case i needed this to troubleshoot quickly an RSS feed on such a > domain. > > It would be nice to have a curl and curl-idn package without me having > to hand roll one. But then where is the limit for a "swiss army knife" > tool? Some linux distro packages come with everything curl can support > compiled in down to gopher...
It could be possible to do a static-linked build of the curl binary in a different port, that would avoid the problems with other ports depending on the library. It is possible to use curl like this, though: $ curl -I https://`idn2 рнидс.срб`/ It's not quite as easy as internal support but doesn't seem too bad.
