Subject: Basic Authentication and encoding of non-ASCII characters in credentials

From: Julian Reschke <[email-masked]>
Date: Tue, 27 May 2008 18:46:28 +0200

Hi,

we recently discussed this over at the W3C webapi discussion list, and 
it turns out that, at least for Firefox, the encoding that is being used 
depends on whether the browser itself does the authentication (ISO8859-1 
plus bugs for non-ISO characters), or whether it's XMLHTTPRequest (UTF-8).

To me that looks like a totally bizarre design.

Feedback appreciated :-)

BR, Julian

PS: to me this looks almost like a show stopper for the FF3 release 
candidate...

---

From: Martin Duerst <[email-masked]>
Date: Wed, 28 May 2008 16:15:10 +0900

At 01:46 08/05/28, Julian Reschke wrote:
>
>Hi,
>
>we recently discussed this over at the W3C webapi discussion list, and it turns out that, at least for Firefox, the encoding that is being used depends on whether the browser itself does the authentication (ISO8859-1 plus bugs for non-ISO characters), or whether it's XMLHTTPRequest (UTF-8).
>

To me, it looks like no design at all. Whoever did the original stuff
didn't think about non-ASCII, or didn't have much of an idea.
In my opinion, UTF-8 is the right long-term solution, and the sooner
we get there, the better.

Regards,    Martin.

>Feedback appreciated :-)
>
>BR, Julian
>
>PS: to me this looks almost like a show stopper for the FF3 release candidate...

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 May 2008 10:51:14 +0200

> we get there, the better.

I would like Basic Auth to use UTF-8. But: this has been discussed again 
and again of the last years, and I think we haven't come to a consensus 
that it *can* be changed.

For instance, I know by first hand of people in Europe relying that 
(non-ASCII) ISO-8859-1 characters in credentials work in Basic 
Authentication, and the clients and servers these people depend on use 
ISO-8859-1 as encoding.

Choosing different encodings in the same UA depending who generated the 
HTTP request is just bizarre, and will not help solving the problem.

It seems an easy way to make progress would be to define "Basic2" (using 
UTF-8), and try to get it supported in the open source browser engines 
(FF/Webkit) and Apache httpd.

BR, Julian

PS: we would still need to discuss whether it should be otherwise 
compatible with Basic, or whether we would want to fix other things as 
well, such as the inability to have colon character in the user name.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 28 May 2008 11:03:42 +0200

Julian Reschke wrote:
> ...

<https://bugzilla.mozilla.org/show_bug.cgi?id=436033>

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 28 May 2008 15:26:51 +0200

Julian Reschke wrote:
 
> I would like Basic Auth to use UTF-8. But: this has been
> discussed again and again of the last years, and I think
> we haven't come to a consensus that it *can* be changed.

> For instance, I know by first hand of people in Europe
> relying that (non-ASCII) ISO-8859-1 characters in 
> credentials work in Basic Authentication, and the clients
> and servers these people depend on use ISO-8859-1 as
> encoding.

Sigh.  This Latin-1 cruft is excessively annoying.  I think
we need a transition strategy (read: modification of the WG
Charter) *how* to replace Latin-1 by UTF-8 in HTTP a.s.a.p.
Two possible strategies:

1 - Keep everything about Latin-1 as is in 2616bis+2617bis,
    and introduce HTTP/1.2 to indicate "same as HTTP/1.1,
    but UTF-8 instead of ISO-8859-1".

2 - Replace Latin-1 by ASCII in 2616bis+2617bis, and after
    years of flamewars upgrade ASCII to UTF-8 for HTTP/1.1.

What's IMO not possible is to do this piecemeal and without
clear strategy.  

> It seems an easy way to make progress would be to define
> "Basic2" (using UTF-8), and try to get it supported in the
> open source browser engines (FF/Webkit) and Apache httpd.

And in most popular browsers (including IE8 and FF3).  

 Frank