https://github.com/metabrainz/musicbrainz-server/pull/686 basically does what Ulrich outlined above, though I'm not aware of any notable clients using digest auth now that Picard uses OAuth. Anyway, since non-ASCII usernames were broken regardless, if clients do nothing then they'll just remain broken.

The draft has since become RFC 7617 (and there is RFC 7616 for Basic, with some complications).

Now, to make this work:

• Catalyst::Authentication::Credential::HTTP needs to be changed to send a header inviting the client to use UTF-8, as defined in the new RFC.
• The same module then must actually treat the provided user name as UTF-8. (There is actually a hack attempting to do it, but it's broken and probably never worked.)
• Clients need to become aware of the new RFC and implement the charset part. As a first step, we should find out what Picard does (it probably uses Python's urllib2), and if it doesn't act correctly, fix that.

with "ordinary webservice" i meant: i can log in fine via https://musicbrainz.org/login (where i fill in a webform with my authentication data).

i can NOT log in via https://musicbrainz.org/ws/2/collection (where an "authentication required" popup springs up which lets me enter my username/password).

i agree that if you have control over both the client (picard) and the server (MBS), you should use the same encoding (so it works in that specific case).

alternatively (or additionally), you might want to check username/password for invalid characters on creation (and eventually forbid them)

The behaviour of HTTP authentication in the presence of non-ASCII characters is undefined (though there is a draft to make UTF-8 the standard), and real-life browsers apparently use different approaches (listed in this SO answer for basic, though I assume it's similar for digest).

So it's unfixable for us; but it is probably a design bug to rely on HTTP auth at all. It might be doable to match the interpretation of Picard and MBS, though, so that at least Picard would work.

btw, logging into the ordinary webservice (not using http basic auth) works as expected.

What do you mean by "logging into the ordinary webservice"? Most other endpoints don't require authentication, and all that do use HTTP digest auth as far as I am aware.