Last Comment Bug 436033 - Inconsistent choice of character encodings for HTTP Basic Authentication
: Inconsistent choice of character encodings for HTTP Basic Authentication
Status: UNCONFIRMED
[necko-would-take]
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: unspecified
: x86 Windows XP
: -- major with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-28 02:02 PDT by Julian Reschke
Modified: 2016-04-14 05:42 PDT (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Julian Reschke 2008-05-28 02:02:01 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008051206 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9) Gecko/2008051206 Firefox/3.0

RFC2617 is not very clear about how to encode non-ascii characters in credentials transmitted using Basic Authentication (http://tools.ietf.org/html/rfc2617#section-2). Some people read it as not specifying at all, some think that TEXT rule from RFC2616 applies here, which would make the encoding ISO-8859-1, potentially enhanced by RFC2047-style escaping.

This bug however is not about what is the right choice. It is about the fact that apparently FF3 has multiple code paths for Basic Auth, and chooses ISO-8859-1 encoding when done through the browser, and UTF-8 when done through the XMLHttpRequest object (at least when the credentials are provided in the open() method).

This is a serious problem: whatever the choice for the encoding is, it needs to be the same consistent choice.

As far as I can tell, existing code depends on ISO-8859-1 encoding (at least in Western Europe), so I would strongly suggest to choose the same encoding (as sad it may be) for XHR as well.


Reproducible: Always
Comment 1 Milos Jakubicek 2008-10-17 15:15:45 PDT
I can at least confirm that Basic Auth uses latin1, which is really disappointing as it makes impossible to submit non-latin1 characters as username/password.

Hence, please please and once again please: if you'll move to make this consistent across Firefox, then move _forward_ and use UTF-8!

Or even better: you should detect user's locale and send in that encoding, that's IMO the very right way how to do this. Otherwise there will be still problems when using non-latin1 characters.
Comment 2 Julian Reschke 2008-10-18 01:06:38 PDT
No, please no more hacking.

The right way to fix this is through the IETF Standards Process, either by changing the default (unlikely, as incompatible), or by introducing a new scheme that uses UTF-8.

And no, the client's locale is totally irrelevant, as the server doesn't know what it is.
Comment 3 Milos Jakubicek 2008-10-18 10:39:55 PDT
(In reply to comment #2)

> And no, the client's locale is totally irrelevant, as the server doesn't know
> what it is.

You mean the server doesn't understand the locale format (en_US.utf8) or the case when the specified encoding isn't available at the server side?

Couldn't the encoding be set somewhere in the preferences, at least on about:config?
Comment 4 Julian Reschke 2008-10-18 11:54:09 PDT
To decode the information, the server needs to know what encoding was used. This information is not in the header.

So, unless all clients use the same encoding, and the server knows what encoding this is, it is not going to work.
Comment 5 Julian Reschke 2010-09-08 08:40:51 PDT
(see also http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-01.html)
Comment 6 David Woodhouse 2014-06-20 01:39:06 PDT
FWIW Chrome just uses UTF-8. Having set my password to include non-ASCII characters, it seems that both Squid and our corporate ActiveSync servers require UTF-8 for Basic auth.
Comment 7 Andreas Wagner [:TheOne] 2016-04-13 02:20:42 PDT
Would it be possible to prioritize this?

I just got locked out of my LDAP account because my password contained non-ASCII characters.
Comment 9 Anne (:annevk) 2016-04-14 00:11:14 PDT
Thanks, that advice seems to have forgotten about market realities. Whereby popular user agents, such as Chrome and Safari, dictate the rules.
Comment 10 Julian Reschke 2016-04-14 05:42:13 PDT
That doesn't parse. The advice is that although servers might use UTF-8 for selected UAs, they mighz be sniffing and continue to expect ISO-8859-1 for Firefox.

That said, if you can switch the default to UTF-8 without breaking to many existing logins, go ahead! (But then please do not blame the specification writers for subsequent Firefox-specific breakage...)

Note You need to log in before you can comment on or make changes to this bug.