W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: XHR LC comments

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 27 May 2008 18:20:28 +0200
Message-ID: <483C34CC.5010304@gmx.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 May 2008 16:21:12 GMT