-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(adr): ADR no. 11 Handling FQDNs #1184
Conversation
doc/adr/0011-handling-fqdns.md
Outdated
|
||
## Decision | ||
|
||
To circumvent current and future troubles with non-ASCII domain names, from the moment the system receives the name during creation of a wiki, it gets encoded to punycode[4] (an encoding allowing unicode via ascii representation), and gets handled only in that format internally. As soon as the value leaves the internal API, it gets decoded to it's original representation in unicode. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are all the places where the domain names get used? How happy are mediawiki, QS, etc. with non-ascii/punycode FQDNs? ElasticSearch?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually remember now testing only using punycode for the k8s ingress, mediawiki wasn't happy about that, I assume similar results for other services. What I'm a bit worried about are the implications for Wikibase and for example results in the Query Service. Can't tell if this would be problematic or be actually the exact right thing to do.
I hate to say it but maybe we should rethink this, see wbstack/api#652 (comment) |
An ADR about handling FQDNs, especially if they consinst of non-ASCII characters.