436033 - Inconsistent choice of character encodings for HTTP Basic Authentication

Status: UNCONFIRMED

(Core :: Networking, defect, P5)

Description

[Julian Reschke]

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]

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]

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]

(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]

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]

(see also http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-01.html)

Comment 6

[David Woodhouse]

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] [use NI]]

Would it be possible to prioritize this?

I just got locked out of my LDAP account because my password contained non-ASCII characters.

Comment 8

[Mark Nottingham]

FWIW: http://tools.ietf.org/html/rfc7617#appendix-B.3

Comment 9

[Anne (:annevk)]

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]

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...)

Comment 11

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.