- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 27 May 2008 18:20:28 +0200
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- CC: "Web API WG (public)" <public-webapi@w3.org>
Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> Yes, the I18N problems of Basic Authentication need to be fixed, but XHR >> is not the right place to do it. > > Agreed, I've repeatedly suggested to simply point out it is up to the > scheme to define how the unicode sequences are encoded in the message. Right. XHR currently says things like: "If the user argument was not omitted and is not null let stored user be user encoded using the encoding specified in the relevant authentication scheme or UTF-8 if the scheme fails to specify an encoding." ...which of course then leads to the question whether the encoding is specified for Basic Authentication. And we all know that this is not really easy to answer. Apparently Anne thinks the UTF-8 defaulting applies to Basic, others (like myself) disagree. So I think the best thing to do here is just to be silent, or to be more verbose and to point out that there currently is no interop for I18N in Basic Auth beyond ISO-8859-1. Finally: if a browser uses different encoding based on how the HTTP request was sent (browser, XHR with credentials in URI, XHR with user/passwrd parameters, XHR prompting for credentials), that's a major bug. Whatever the encoding is, it needs to be selected in a deterministic way. Otherwise, how is the server supposed to know how to decode the credentials??? BR, Julian
Received on Tuesday, 27 May 2008 16:21:12 UTC