Our German customers frequently ask to start supporting the German “ß” character in Plesk. The character is also known as “sharp-s” or “Eszett”. So why don’t we just fix this problem?
Well, the answer is that the problem is not in Plesk and is not at the server-side at all. As you may know, international (in fact, national) characters were enabled in domain names with IDNA 2003 protocol, which introduced a procedure converting national names (German, Cyrillic, Chinese, etc) into something looking like xn--fa-hia.com. The idea was that national domain names would be equally converted into such an ASCII string on the client side (browser) and on the server side (DNS and Web servers), thus all existing Internet protocols would easily pass this converted ASCII string without any modification. Cool? Exactly! Except that original IDNA 2003 protocol didn’t support several characters properly and one of those was “ß”. It was interpreted as mere ‘ss’. So “faß.de” domain (for example) was processed as “fass.de”, ignoring the national character.
After a while, the problem was resolved with the new IDNA 2008 protocol introduced, which recognized “ß” as a national character and the new procedure was converting it properly. Some registrars allowed registration according to IDNA 2008 in .de, .be and .fr zones. Cool? Exactly! Except that to make the protocol work, there is a need in the agreement between the client-side (browser) and the server. And there were no such an agreement. Teams that developed most of the browsers were concerned about possible phishing, which could happen if they changed the procedure. Indeed – yesterday you wanted to open “faß.de” and went to “fass.de”, but if they changed the procedure, you would go to another domain “xn--fa-hia.de”. Technically, they are different and may belong to different people. So, what if someone else would register such a domain and would use the changed procedure to their advantage, pretending to be your usual e-shop and collecting your credit card data? Considering that, all major browsers refused this new procedure and remained on the so-called “transitional IDNA 2008“, which has all advantages of IDNA 2008, but still interprets the tricky character exactly in the same way as before: “faß.de” goes as “fass.de”.
As you can see, none of major browsers plan to fully support IDNA 2008; they will only support the transitional IDNA 2008:
- MS Internet Explorer implements IDNA 2008 transitional mode – sends to ‘ss’-version, no full IDNA 2008 is planned.
- Google Chrome implements IDNA 2008 transitional mode – sends to ‘ss’-version, no full IDNA 2008 is planned.
- Mozilla Firefox implements IDNA2003 currently, and currently sends to ‘ss’-version.
- Apple Safari doesn’t support full IDNA 2008, a relevant bug on WebKit is still open; Safari currently sends to ‘ss’-version.
- Opera is currently based on the Blink engine and it implements transitional IDNA 2008.
Reportedly, Opera supported full IDNA 2008 in v12.15, but then cancelled in Opera Next (v17), when it switched to the Blink engine.
That said, Plesk sticks to the browser-compatible behaviour and implements transitional IDNA 2008. As illustrated below that is the only way of letting visitors access a site, unlike “correct” full IDNA 2008 procedure:
So, how would this limitation affect people in practice ? Well, given possible fraud with ambiguous interpretation of domain names, some registrars required or suggested people to book both IDNA 2003 version of domain name (“fass.de”) and IDNA 2008 version of it (“faß.de”). Once both names were purchased, an owner would try to set up them both in Plesk. However, in transitional IDNA 2008, both names are identical (“fass.de”), so Plesk will refuse. If users are familiar with IDNA 2008 rules, they can carry out a DNS test and see that the Plesk’s interpretation of their domain (“faß.de” >> “fass.de”) doesn’t match the one suggested by their registrar (“faß.de” → “xn--fa-hia.de”).
The easiest solution is to add only one of the two domain names in Plesk, i.e. “faß.de”. It will work well for every practical need and will keep a customer’s site available to visitors.