On Tue, Feb 10, 2009 at 09:52:43AM -0500, Eric Covener wrote: > 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?
That's probably a better way to put it, yes. > > 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. OK, even worse choice of language there, including the spelling. But that is the point: it's extrapolating from the behaviour of a couple of browsers, rather than following any RFC... ... > 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. ... and hence leads to interop failure. > 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. I think it would be better to simply advise against use of non-ASCII usernames in the docs. Regards, Joe
