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

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

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.


Received on Sunday, 16 May 2010 21:46:01 UTC