W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: Missing specification in RFC 2617, cannot use a user name nor a password in encoding different from ISO-8859-1

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Sun, 16 May 2010 23:45:29 +0200
To: Honza Bambas <hbambas@mozilla.com>
Cc: ietf-http-wg@w3.org
Message-ID: <1274046329.3630.70.camel@localhost>
mån 2010-05-03 klockan 21:46 +0000 skrev Honza Bambas:

> My question is: should we disallow acceptance of a user name or
> password input in encoding different from ISO-8859-1 on the client
> side (independently on a server being setup for it, in any way) or
> should there be defined an extension to RFC 2617 allowing
> communication of the encoding between the client and the server?

PLease go ahead and propose an extension where the server initiates
negotiation of another charset than ISO-8859-1 (preferably UTF-8).

Such extensions to 2617 is currently outside the scope for HTTPbis WG
charter, but it's perfectly fine to discuss them here on the
mailinglist.

For basic it's trivially done by introducing a charset=utf8 parameter in
both challenge & response. Note: requires extending response format to
add parameters after the base64-response.

digest syntax is also trivially extended with a new charset parameter
and within existing syntax, but requires a bit more thought on how the
username should be encoded. I would vote for doing encoding on the raw
username before hasing, while keeping the password as-is making it
trivially compatible with existing digest server implementations. But
would also work encoding the username in the header output only and hash
on the raw value. A study of how existing digest auth backend stores
handles the hashing may be in place here, but should only be seen as
input not recommendation.

It's also worthwile to examine the Digest related efforts by SASL and
Radius working groups which both have touched this area.

Regards
Henrik
Received on Sunday, 16 May 2010 21:46:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:18 GMT