Found another issue in Safari 3, where the unescaping and punycoding are done in the wrong order. Here's an example: <a href="http://十%2ecom/">link</a> When you click on that link, Safari ends up sending the following (wrong) domain name to DNS: xn--.com-9b5j This is because Safari is first running the host name through IDNA to get Punycode and *then* unescaping the %2e to get the dot. It should first unescape the %2e to get the dot, and then separate the host name into labels, and then run IDNA on the 1st label only, since it is non-ASCII. The result should be xn--kkr.com. Both MSIE 7 and Opera 9 get this right, but Firefox gets it wrong, in a different way. This bug may be more serious than the following, since it affects how a hostname is divided into labels at each dot. http://bugs.webkit.org/show_bug.cgi?id=13167 I suspect that both of these bugs would be fixed by a single check-in.
Can you put the HTML snippet you mentioned into an attachment on the bug? Bugzilla has a habit of mangling non-ASCII characters which makes it hard to decipher your original snippet.
Created attachment 18047 [details] HTML snippet with %-escaped dot in host name
<rdar://problem/5803718>
I am not sure on expected behavior but unlike other browsers - Safari 15.6 on macOS 12.5 briefly (few second) change the URL of webpage but then change back to Webkit attachment and get stuck in loading forever this webpage and then fail eventually and even show "Safari can’t open the page “十.com”" in the error message. All other browsers don't update their URL box but give this error message: Firefox Nightly 104 - The server at xn--kkr.com is taking too long to respond. Chrome Canary 106 - 十.com took too long to respond. I am not sure on Web-spec but please update this bug accordingly. Thanks!
Yeah, I agree that is weird. That is a different problem from comment 0, but seems worth tracking.