+++ This bug was initially created as a clone of Bug #41489 +++ There needs to be some way for a server to tell the client what encoding it expects for basic auth credentials, and the client needs to respect that choice. The solution must be implementable by server admins of common servers (IIS, Apache, nginx) using mod_headers-like approaches--without requiring code changes to HTTP servers, proxies, or web apps. The solution must be backward-compatible so that IE6/7/8/9, Safari, and other browsers can safely ignore it. The solution must work for both origin server authentication and proxy authentication. One potential solution is http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html. However, I am concerned that this might not meet the requirements in the previous paragraph. Separate "Authenticate-Encoding" and "Proxy-Authenticate-Encoding" header fields would clearly meet them. We should come try to an agreement with other browser makers on a way forward, ideally we should have a prototype of this mechanism (e.g. with "X-Moz-" prefixes) in the release where bug 41489 is resolved. The mechanism needs to be documented on MDC when we start shipping it. We should also dogfood it on *.mozilla.org.
Test cases for extension auth-params: http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam1 and http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2 These seem to work in all current browsers.
Proposed specification defining an extension parameter for servers to opt-in to UTF-8: <http://greenbytes.de/tech/webdav/draft-ietf-httpauth-basicauth-enc-02.html>
The IESG just approved a revision of the Basic Auth spec that defines the aforementioned "charset" parameter (to be published as RFC soon): http://greenbytes.de/tech/webdav/draft-ietf-httpauth-basicauth-update-07.html
Jason, should we jump on this? (see comment 3).
Sure--it would be great to finally fix basic auth encoding.
Do you think you can find an assignee for this?
Assignee: nobody → jduell.mcbugs
Assignee: jduell.mcbugs → nobody
see also the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=41489
The work looks like it's happening back in the original bug, so I'm duping this.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 41489
You need to log in before you can comment on or make changes to this bug.