I'm not sure that ...ByLanguage is correct either. The AuthLDAPConvertFromLanguage directive can take either a language identifier (es, de, fr, en, etc.) or a charset (ISO-8859-xx, etc). The end result should be a character set ID that can be passed to apr_xlate_open(). I am thinking that maybe the best name would be "AuthLDAPCharsetConversion <from> <to>" where <from> would be the language or charset that you are converting from and <to> would be the character set that you are converting to (obviously). Since LDAP expects UTF8 encoding, if <to> is omitted then the default would be UTF8 since it doesn't really make any sense to convert to anything else. The <to> parameter is only available to allow the user to specify the correct UTF8 string ID that corresponds to the platform's implementation of iconv() (if that is even an issue???).
I thought about implementing the UTF8 conversion through an input filter, but I'm not sure I want to take that task on yet. I am also not sure that the two issues are related anyway. LDAP needs a specialized conversion. It only needs to have the user name portion of the authentication string converted to UTF8. A filter would UTF8 encode everything which wouldn't necessarily be correct. I see some issues with it anyway. 1. Why should all requests take the conversion hit if it isn't needed or wanted? 2. LDAP, at least the Novell LDAP SDK, can not deal with encoded passwords. The password part of the authentication header must not be UTF8 encoded. 3. How do you deal with decrypting->converting->encryption the authentication header so that the conversion to UTF8 is transparent to the rest of the code? Base64 may not be a problem, but what about digest? 4. Other authentication modules do not expect UTF8 and would have to be retrofitted. Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Friday, December 06, 2002 11:07:05 PM >>> At 03:42 PM 12/6/2002, Brad Nicholes wrote: > This patch adds a new directive "AuthLDAPConvertFromLanguage" to mod_auth_ldap >that allows the admin to either define a specific language when converting the user >ID to UTF8 of try to derive the language from the header. Ewww... charsets aren't languages. '...ByLanguage' would be more appropriate. More to the point... all headers suffer from this problem. If we are going to address dealing with non-utf-8 headers into a canonical utf-8 form, I'd prefer some directive to deal with this across the board. Win32 would actually prefer to deal in utf-8 identifiers, and if we invest the energy in 'fixups' for one canonical header (user/passwords) then we aught to think about dealing with them all in one place. And that place wouldn't be in ldap, but more likely in a module like mod_charset_headers or something that will just deal with all of the implications of HTTP/1.1's inbound 'opaque' high-bit characters; perhaps we fix outbound header fields as well. Just my (selfish) 2c :) Bill p.s. honest - hadn't even read on to Andre's response when I wrote the response above, but +1 to his observations :)