https://bz.apache.org/bugzilla/show_bug.cgi?id=61193
--- Comment #1 from Jakob Hirsch <[email protected]> --- sorry, the line should sayd "UTF-8 utf8", not "... utf", obviously. The reason for the issue is probably in mod_authnz_ldap.c: authnz_ldap_post_config(), line 1902: to_charset = derive_codepage_from_lang (p, "utf-8"); derive_codepage_from_lang() first tries to find the language ("utf-8" in this case). if this fails, it shortens language to two chars by setting "language[2] = '\0';". But language is set to the static string "utf-8", stored in a read-only data segment or with the program code (also read-only), so it cannot be changed. Unrelated but notable: Since derive_codepage_from_lang() cannot even know wether language points to memory longer than 2 bytes, this is bad style (at least). You don't want to crash (or worse) just because some client has single or zero char element in his Accept-Language header (didn't check if this is not catched otherwise). I _guess_ the intention was the provide a fallback for something like "en-US" to simply "en", if the former is not configured, so the logic itself is not that bad, but sloppy implemented. First, shortening "UTF-8" or "Unicode" (examples from conversion.conv) to two chars does not make sense, "UT" or "UN" could be some real language extension. The check in line 129 should at least be extended to something like this: if (!charset && strlen(language) > 2 && language[2] == '-') ... This will not help against somebody calling derive_codepage_from_lang() with a static "xy-ZZ", of course, so to be really safe, we would also need rw memory (something like strndupa). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
