W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2003

Re: RFC 2617 Authentication and character sets revisited

From: Scott Lawrence <scott-http@skrb.org>
Date: Wed, 26 Nov 2003 15:23:17 -0500
To: ietf-http-wg@w3.org
Cc: yngve@opera.com
Message-ID: <uoeuvxs2t.fsf@skrb.org>

Yngve Nysaeter Pettersen <yngve@opera.com> writes:

> But will the binary representation of the username in the authentication
> header match the binary representation in the server's database?
> The configuration procedure can be done through webforms, which may or may
> not have character sets defined, or through a Telnet/SSH connection to the
> server, just to mention two possibilities.
> And there is no way to tell the client which character set and encodings
> were used during the registration process.
> An example: The Norwegian spelling of my middle name contains the letter
> "" (ae, 0xE6). In iso-8859-1 and iso-8859-15 the binary representation is
> the same, but in UTF-8 it has a different representation and will not exist
> in most other character sets. Depending on the servers' registration
> procedures, I may be able to register a username containing that character,
> even if the server does not know the character set, but unless the
> registration process and the actual login somehow results in the same
> binary representation I will probably not be able to log in.

I don't think I understand your example.  If my server gets a
user="foo" and 'foo' does not appear in my database of valid users,
then authentication has failed.  The username value is already covered
by the existing rule for TEXT:

rfc2617, sec 3.2.2:

       username         = "username" "=" username-value
       username-value   = quoted-string

rfc2616, sec 2.2:

       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
       qdtext         = <any TEXT except <">>

so the username has to be done using the clunky existing mechanism. 

Scott Lawrence        
Received on Saturday, 29 November 2003 07:42:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:24 UTC