On Tue, Feb 10, 2009 at 8:45 AM, Joe Orton <[email protected]> wrote: > The AuthLDAPCharsetConfig directive allows server admins to do charset > conversion of the username passed in the HTTP auth headers. > > RFC 2617 does not specify use of encoding non-ASCII usernames in the > {Proxy-},Authorization request headers; mod_authnz_ldap is guessing an > encoding based on any Accept-Language header in the request. Given that > use of non-ASCII in HTTP authz is not specified by RFC, this is:
Isn't it encoding agnostic, with the exception of ascii control characters? > a) imposing a defacto standard, and I had assumed it was compiled from browser observation, which would make it a little more reactionary than it's painted here. > b) setting an false expectation that use of non-ASCII usernames will > actually work with HTTP, and I agree that this partial/fuzzy solution is costly in terms of support > c) not going to work in practice, as I just had a user complain. When I looked at it, I thought it minimally needed to know user-agent details and possibly some heurisitc to double-check the utf8-or-local-codepage guess. For example my notes imply the current scheme would have trouble with recent Opera releases, which favor utf-8 for the encoding of the basic auth credentials. > > So it seems like a bad idea all round. Am I missing anything? > IMO makes sense at the very least to call out that it's a heuristic that shouldn't be relied upon. Being influenced by e.g. BrowserMatch, or the presence of certain sequences provided by the user would go a long way in at least helping a savvy administrator accomodate the unpredictable incoming charset. -- Eric Covener [email protected]
