For example, when copy-pasting a server name from a webpage the user can often accidentally include a space at the end or in the beginning. When pasting the server name into the ThinLinc client it can be difficult to spot, especially a trailing space.
If I am interpreting the RFC for IDNA correctly, the DNS-names are not allowed to contain spaces: https://tools.ietf.org/html/rfc5890 > string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. like all DNS labels, its total length must not exceed 63 octets.
(In reply to comment #2) > If I am interpreting the RFC for IDNA correctly, the DNS-names are not allowed > to contain spaces: > > https://tools.ietf.org/html/rfc5890 > > > string consisting of ASCII letters, digits, and the hyphen with the further > > restriction that the hyphen cannot appear at the beginning or end of the > > string. like all DNS labels, its total length must not exceed 63 octets. Disregard this. Apparently for a the quote from above describes something called "NR-LDH labels" but there are two other types which are also allowed for IDNA labels. I get a headache from reading this RFC. According to wikipedia, whitespace is not allowed in hostnames: https://en.wikipedia.org/wiki/Hostname Good enough for me :)
(In reply to comment #3) > According to wikipedia, whitespace is not allowed in hostnames: > > https://en.wikipedia.org/wiki/Hostname > > Good enough for me :) And that page did not consider IDN, so not good enough. ;) But looking at RFC 3492 (Punycode) is much more telling: > ... > The basic code points are the ASCII [ASCII] code points (0..7F)... > ... > All basic code points appearing in the extended string are represented > literally at the beginning of the basic string, in their original > order... > ... And in RFC 5890 (IDNA): > ... > An "A-label" is the ASCII-Compatible Encoding (ACE, see > Section 2.3.2.5) form of an IDNA-valid string. > ... must conform to all requirements for a label that can be stored > in the DNS including conformance to the rules for LDH labels > (Section 2.3.1). > ... > Any rules or conventions that apply to DNS labels in general apply to > whichever of the U-label or A-label would be more restrictive. There > are two exceptions to this principle. First, the restriction to > ASCII characters does not apply to the U-label. Second, expansion of > the A-label form to a U-label may produce strings that are much > longer than the normal 63 octet DNS limit (potentially up to 252 > characters) due to the compression efficiency of the Punycode > algorithm > ... IOW, since: a) all whitespace is in the ASCII range b) ASCII code points are copied as-is to the A-label c) An U-label is only valid if it's A-label is valid d) An A-label must follow the classic requirements on DNS labels Then whitespace is not permitted in an IDN name (U-label) as there is no way to convert it to an A-label that is valid. (every codepoint above 0x7f seems to be fair game though, even the new whitespace ones there)
After discussion on meeting: "Keep the eye on the ball". We should not try to solve every theoretical problem; just the main reported issue. IOW, most common problems are space and tab. We should also check if this problem extends to the username and password.
Fixed and tested by mob-programming!
