Re: [Ietf-http-auth] Updating RFC 2617 (HTTP Digest) to use UTF-8

While we're on this subject... In rfc2617 secction 3.2.1, it says:

> realm
>      A string to be displayed to users so they know which username and
>      password to use.

It would be also nice to define the encoding of the realm string so  
that clients that display the realm to users can display it correctly.  
We've seen realms from servers encoded UTF-8, ISO-8859-1, and with  
various Windows encodings. There's no good way to guess which encoding  
to use and so whatever is used is currently wrong on some servers.

All the best,

Jim

On Sep 25, 2006, at 11:31 AM, Lisa Dusseault wrote:

>
> I agree it would be good to update RFC2617.  Is anybody going to  
> take a stab at it?
>
> Lisa
>
> On Sep 22, 2006, at 7:55 PM, Martin Duerst wrote:
>
>> Many thanks to Bjoern for the detailed checking and report.
>>
>> My summary of the situation would be as follows:
>> There is currently widely varying practice. Current implementations
>> are anyways broken and non-interoperable. The main reason for this
>> is most probably that there is no clear specification. This means
>> that an update of RFC 2617 is desirable. The new specification
>> should probably go for UTF-8, while noting that there is still
>> some varying practice.
>>
>> Regards,   Martin.
>>
>>
>> At 01:41 06/09/23, Bjoern Hoehrmann wrote:
>>> * Alexey Melnikov wrote:
>>>> Does anybody know if updating RFC 2617 to say that username/ 
>>>> passwords
>>>> are UTF-8 would break any major implementation? For example, does
>>>> anybody know if a major HTTP client/server implementation assume  
>>>> ISO 8859-1?
>>>
>>> It appears that for Basic authentication the german version of  
>>> Internet
>>> Explorer 6 running on the german version of Windows 2003 as well  
>>> as the
>>> latest english Internet Explorer 7 release candidate running on the
>>> german version of Windows XP will use something like ISO-8859-1  
>>> for both
>>> manual as well as XMLHttpRequest requests. Trying to use U+20AC as  
>>> user
>>> name and password they got encoded as 0x80 (Windows-1252) for  
>>> manual re-
>>> quests, and to '?' for XHR. Characters not included in  
>>> Windows-1252 come
>>> out as '?' regardless of the method used. For XHR my test cases  
>>> include
>>> documents encoded as ISO-8859-1 and UTF-8; there did not appear to  
>>> be
>>> any difference.
>>>
>>> The latest en-us version of Firefox uses UTF-8 for XHR and the lower
>>> byte of the character when encoded using UTF-16BE (so for U+20AC you
>>> get 0xAC) when using manual input. For manually entered http:// 
>>> u:p@...
>>> URLs Firefox uses Windows-1252 if possible, UTF-8 otherwise. When  
>>> XHR
>>> is used with such a URL, it uses UTF-8. The latest en-us version of
>>> Opera9 always uses UTF-8, as far as I can tell based on my limited
>>> testing. Results might well be different on with different default  
>>> code
>>> pages, language settings, and so on. Note that the illegal http:// 
>>> u:p@..
>>> addressing scheme allows to use arbitrary octet sequences using %hh
>>> escape sequences, with some browser-specific limitations.
>>> -- 
>>> Bj�n H�rmann キ mailto:bjoern@hoehrmann.de キ http://bjoern.hoeh 
>>> rmann.de
>>> Weinh. Str. 22 キ Telefon: +49(0)621/4309674 キ http://www.bjoernsworl 
>>> d.de
>>> 68309 Mannheim キ PGP Pub. KeyID: 0xA4357E78 キ http://www.websitedev 
>>> .de/
>>> _______________________________________________
>>> Ietf-http-auth mailing list
>>> Ietf-http-auth@osafoundation.org
>>> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
>>
>>
>> #-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
>> #-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@it.aoyama.ac.jp
>>
>> _______________________________________________
>> Ietf-http-auth mailing list
>> Ietf-http-auth@osafoundation.org
>> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http- 
>> auth
>
>

Received on Tuesday, 26 September 2006 00:34:51 UTC