Web hosting tools enable people and organizations to have a website accessible on the Internet. They rely on web servers, email servers and backend databases to provide the building blocks of a website’s functionality in the digital world. The question is do they provide seamless experience for users using internationalized email or using a new localized top-level domain (TLD)?
Together, the Universal Acceptance Steering Group (UASG) and Nexperteam conducted a study to assess to what extend three of the most widely used web hosting tools, cPanel, Plesk, and ISPConfig offer the capacity for customers to build websites and host emails in accordance with Universal Acceptance objectives.
The assessment focused on all basic functions; this means the activation and management of the domain name as well as the webhosting and email service provided are IDN enabled, accept Unicode strings and provide an easy and transparent way of working with them throughout the interface.
We performed the assessment against nine different configurations on different operating systems (Linux and Windows for Plesk, Linux for cPanel and ISPConfig) and the following native scripts: Arabic, Cyrillic (Bulgarian), Devanagari (Hindi), Greek, Hangul (Korean), Malayalam, Telugu, Thai, Simplified Chinese, Traditional Chinese, Latin (French).
The assessment reveals that although the three web hosting tools have embraced UTF-8 to a certain extent, none provides a full-native script experience. The reason often being that underlying services are not ready to support these native scripts, so the web hosting tool providers have currently taken the prudent road of blocking any non-ASCII characters throughout most of their interface.
Let’s look at the overall assessment results per web hosting tool feature.
Environment configuration
When installing the different Linux distributions, it is obvious that installing any of these has become quite straight forward. Most of the underlying software does support UTF-8 character sets in some form either out of the box, either by some simple changes in the configuration. For instance, all installed FTP services are configured to use a database. The link with this database is UTF-8 compliant if the database is set to be UTF-8 compliant.
The same goes for tools such as virus scanner, SPAM protection, database, DNS and file storage. The Linux user management system does allow for UTF-8 compliant users albeit with the note that you would have to supply the “–badname” flag to create the user.
Some of the tools installed are already embracing the UTF-8 character set and the various languages from all over the world. Most notably phpMyAdmin, the tool to manipulate the database and its content via a web interface and RoundCubeMail, a tool to read and manage your personal email box via a web interface.
Access (accounts creation)
Visiting the web hosting tools shows that all three take the prudent approach of blocking UTF-8 characters when it comes to user identification and email addresses. A decision that in light of the above arguments is certainly understandable.
We took the liberty to circumvent a number of these on ISPConfig. Since this tool is open source it can easily be adapted and changed at will. If one does make this type of change, it shows the strengths and the weaknesses of the underlying system and services. Some are quick and easy fixes as for instances with the DNS provided system. Here the accept, validate, process and store cycle have been ironed out already. Both UTF-8 as well as IDNA A-labels can be provided. The only thing missing is the display step where the names are visualized in the ASCII -based format rather than the wanted UTF-8 format. By simply adding the filter that already is provided, the display part can be fixed to do the right thing.
At this point most of the services have embraced UTF-8 to a certain extent. With little effort, some of the experience can be made a lot less painful. All web-hosting tools do provide a set of languages they support and allow a specific language to be added on demand.
Some of the tools allow for an almost 100% web based experience. If all underlying services would support UTF-8 it would be possible for small businesses to create and manage their web presence and email through an all-native interface. However due to the lack of support of some tools at this point none of the web hosting packages even are close to providing such an experience.
There were certainly some disappointing details where the lack of compliance shows. One of the major pain points is email.
It is worth mentioning that none of the web servers and Email servers have UTF-8 enabled by default. They require additional steps to enable it. However, although UTF-8 support was enabled for email servers, the Email tests didn’t pass.
Postfix, the most used tool to send and receive email can be configured to support SMTPUTF8. However, unfortunately only the local part of the email address can be shared in UTF-8 format. The part specifying the domain name must be converted to IDNA A-label to be accepted.
Going further down the email path the service that provides POP and IMAP delivery services does not support UTF-8. So even if the tool sets described above would be made UTF-8 compliant and the web-hosting tool would allow for UTF-8 email addresses the delivery would still fail.
Getting the email system to work turns out to be a bit of a nightmare. Although setting up the web interface to accept UTF-8 email address turns out to be just a small challenge, getting the full service stack to work tis an even more daunting task. Not even the build-in PHP email check on which ISPConfig relies allows UTF-8 characters, neither in the local part, nor in the domain name part.
Domain
cPanel does not allow creation of IDNs and zone records in native scripts. You have to use an external IDN converter and create domain names and add zone records only in punycode. This affects the user experience heavily as it would make it nearly impossible to manage your DNS records from within the provided web-hosting tool.
Plesk on Windows allows creation of IDNs and zone records in native scripts and their proper visualization of DN in the interface, Plesk on Linux allows it, except for Malayalam. For Malayalam, Plesk on Linux fails in some situations (it does not work out for some domain names). The Plesk team will investigate this.
ISPConfig requires installation of an additional patch for the proper visualization of IDNs in the web interface.
Databases
Both cPanel and Plesk do not allow creation of databases and DB users in native scripts.
When allowing native script databases to be generated from the ISPConfig web interface it seems we are facing a double or mismatching encoding problem. Although the metadata such as database name and database user seem to be validated and stored consistently, we can clearly see it is not visualized correctly. We are not sure if this is due to a misconfiguration in the PHP MySQL layer or if this is related to a MySQL library mismatch problem. Further examination is needed but deemed out of scope for this particular study.
Web Hosting
Another thing to consider is the client tools that must be used to actually access the web hosting tools. Notably if you try to upload files, you will need an FTP/SFTP client. Although there are many of these tools, are they providing this service in native scripts and are they allowing UTF-8 login credentials?
Obviously, these questions were out of scope for this assessment.
Conclusion
Considering the three web hosting tools, at this point we believe that Plesk has the highest chance of providing a full native script experience. The main reason is that Plesk combines a file access tool in its offering. As such, the whole user experience could be driven through a web interface. With Plesk email, domain name, user, database and files can be managed using various different web services all available from your local native script supporting web browser.
Such tools could also be installed on the other web hosting tools making those fully web browser managed but this will require additional installation and configuration steps.
On the other hand, ISPConfig has the advantage of being an open source web-hosting tool and allows making ad hoc changes. For those willing and capable of doing their own patches and updates this might be a good way forward to implement a full native script experience.
To make the web hosting tools providers aware of the importance of being UA-ready, during and after the assessment completed, bug reports and feature suggestions were submitted to cPanel and Plesk for potential UA remediation.
Although the results of the assessment were not encouraging, we hope that the web hosting tools providers will work together with the underlying service providers to enable the support of native scripts in the near future.
More information on the assessment objectives, process, and results is available in the full report: UASG042 – UA-Readiness of Web Hosting Tools Report.
Leave A Comment
You must be logged in to post a comment.