Hello, I tested how Authorization Basic implementations handle Japanese characters. Tests done in Japanese environment on MacOS X (10.9.2).
Safari 7.0.2 (9537.74.9) * If any Japanese Characters (Kanji, Hiragana, etc) exist in either username or password, Safari does not produce any Authorization header at all, even without any error messages. It behaves as if password was incorrect, from the user's point of view. * You might want to try the same with European accented characters above U+00FF. Firefox 27.0.1 * lowest 8 bit of the Unicode code point, 1-byte for each character. Chrome 33.0.1750.117 * UTF-8 precomposed (this is what we expect). CJK characters have problems (except Chrome) in this respect. Japanese users are well familiar with avoiding non-ASCII usernames and passwords. :P Best regards, -- Kaoru Maeda <[email protected]> Lepidum Co., Ltd. 2014-02-15 0:56 GMT+09:00 Julian Reschke <[email protected]>: > On 2014-02-14 16:18, Bjoern Hoehrmann wrote: > >> Hi, >> >> On the German Apache HTTPD users mailing list someone was having >> difficulties using non-ascii characters in HTTP Basic Authentication >> and posted these test results, >> >> TortoiseSVN >> Password: "E EURO D$P§äöü123" >> Hex: "45,E2,82,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> Chrome >> Password: "Eâ?¬D$P§äöà 1/4 123" >> Hex: "45,C3,A2,C2,82,C2,AC,44,24,50,C3,82,C2,A7,C3,83,C2,A4,C3, >> 83,C2,B6,C3,83,C2,BC,31,32,33" >> >> Internet Explorer >> Password: "E?D$P§äöü123" >> Hex: "45,C2,80,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> Firefox >> Password: "E¬D$P§äöü123" >> Hex: "45,C2,AC,44,24,50,C2,A7,C3,A4,C3,B6,C3,BC,31,32,33" >> >> I analysed these samples and TortoiseSVN does just plain UTF-8, Chrome >> does double-UTF-8, and IE and Firefox first apply Windows-1252 and then >> UTF-8 on the result. I do recall Firefox doing something worse but could >> not find the bug report when I briefly looked for it... >> > > With my test server, the username "test" and the password "E EURO D$P§äöü123" > I > see: > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 >> Firefox/27.0 >> Raw authentication header: Basic dGVzdDpFrEQkUKfk9vwxMjM= >> Decoded as byte sequence: 74 65 73 74 3a 45 ac 44 24 50 a7 e4 f6 fc 31 32 >> 33 >> Decoded as ISO-8859-1: test:E¬D$P§äöü123 >> Decoded as UTF-8: test:E?D$P???? >> > > Firefox: the EURO ends up as 0xac, so it appears the lower 8 bits of 20ac > have been sent. > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like >> Gecko) Chrome/32.0.1700.107 Safari/537.36 >> Raw authentication header: Basic dGVzdDpF4oKsRCRQwqfDpMO2w7wxMjM= >> Decoded as byte sequence: 74 65 73 74 3a 45 e2 82 ac 44 24 50 c2 a7 c3 a4 >> c3 b6 c3 bc 31 32 33 >> Decoded as ISO-8859-1: test:Eâ?¬D$P§äöà 1/4 123 >> Decoded as UTF-8: test:E EURO D$P§äöü123 >> > > Chrome: proper UTF-8. > > UA: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko >> Raw authentication header: Basic dGVzdDpFgEQkUKfk9vwxMjM= >> Decoded as byte sequence: 74 65 73 74 3a 45 80 44 24 50 a7 e4 f6 fc 31 32 >> 33 >> Decoded as ISO-8859-1: test:E?D$P§äöü123 >> Decoded as UTF-8: test:E?D$P???? >> > > IE: sends the EURO as 0x80, which probably make sense from their point of > view ;-) > > Best regards, Julian > > > > _______________________________________________ > http-auth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/http-auth >
_______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
