Subject: [http-auth] test results for non-ASCII characters in Basic Auth

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Feb 2014 17:25:02 +0100

Hi there,

testing with the attached code and german unlauts.

Results:

1) The platform does not appear to matter.

2) IE and Firefox send ISO-8859-1

3) Chrome sends UTF-8 (precomposed)

4) Safari appears to send ISO-8859-1 on the first request, then UTF-8 
(precomposed) (anybody have an idea what's going on?)

5) wget and curl send UTF-8 (precomposed)

And, somewhat unrelated:

6) none of the clients seems to enforce the "no-colon-in-username" 
constraint.

So it appears we can require NFC in case UTF-8 is used.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 05 Feb 2014 22:37:05 +0100

On 2014-02-05 17:25, Julian Reschke wrote:
> ...
> ...

...which is a result of how the shell mapped the characters before 
invoking the tools.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Feb 2014 15:42:28 -0600

On Wed, Feb 5, 2014 at 3:37 PM, Julian Reschke <[email-masked]> wrote:
> ...which is a result of how the shell mapped the characters before invoking
> the tools.

The shell had nothing to do with it.  It was the input mode and/or
[pseudo-]terminal.  You could manually encode a decomposed sequence
(e.g., with the printf(1) shell built-in, if you have a modern-enough
shell) and try cat'ing that into the right place and it should get
passed through as-is (decomposed).

For this reason I think one of the interesting things to do is gather
information about input mode behavior.  And not just for Latin
scripts, but also Hangul and a few others with pre-composed and
decomposed equivalents.

Nico
--