GNOME Bugzilla – Bug 747376
Doesn't show IDN domain names
Last modified: 2016-12-18 21:15:28 UTC
Go to: http://thepiratebay.xn--q9jyb4c/ Epiphany shows: http://thepiratebay.xn--q9jyb4c/ as the URL when it should show: http://thepiratebay.みんな/
Here's a test page that requires a bit less bravery to visit: http://xn--rksmrgs-5wao1o.josefsson.org/ It should be displayed as: http://räksmörgås.josefsson.org Unfortunately I have no clue what to do here. It's not reasonable for Epiphany to implement this itself, so I guess WebKit should expose a function to format such URIs for display. The page itself hints at another problem: that first link is going to stop working in WebKit soon, since we've finally switched from IDNA2003 to IDNA2008....
It looks like this is exposed by ICU. We could probably use that in Epiphany. It's already an indirect dependency via WebKit, and it would probably be better than adding new WebKit API.
https://bugs.webkit.org/show_bug.cgi?id=126627 is a problem, though: this would expose us to IDN homograph attacks which even WebKit doesn't yet have a solution to.
(In reply to Michael Catanzaro from comment #1) > The page itself hints at another problem: that first link is going to stop > working in WebKit soon, since we've finally switched from IDNA2003 to > IDNA2008.... There's a spec for this too: http://www.unicode.org/reports/tr46/
The following fix has been pushed: 6b7c6de uri-helpers: Use ICU to decode punycode for display
Created attachment 342081 [details] [review] uri-helpers: Use ICU to decode punycode for display This adds support for properly displaying IDNA URIs, instead of showing punycode-encoded URIs. ICU is already a dependency of WebKit.
The following fixes have been pushed: fc88dce uri-helpers: Cache the UTS #46 context 05d81a5 uri-helpers: be robust to NULL SoupURIs
Created attachment 342083 [details] [review] uri-helpers: Cache the UTS #46 context We need a mutex to do this, to ensure that we don't leak in the unlikely event that this function is called for the first time in multiple threads at once. Originally, I thought it made sense to create a new context for each call to this function, to avoid the mutex lock, but it uses a mutex internally during creation anyway, so that's an illusory cost, and it seems to do a substantial amount of work.
Created attachment 342084 [details] [review] uri-helpers: be robust to NULL SoupURIs This probably should never happen here, but there's no reason to crash if it does.
The following fix has been pushed: 90c7799 uri-helpers: Pass larger buffer to ICU
Created attachment 342184 [details] [review] uri-helpers: Pass larger buffer to ICU Our buffer was one byte too small to hold the longest-possible domain name. Also, we need to make sure the buffer is one byte longer than we tell ICU. Fill it with zeroes so that we can guarantee it remains NUL- terminated. It's hard to believe that U_STRING_NOT_TERMINATED_WARNING is a thing, but it is and we don't want to hit it....