On Saturday 25 June 2011, Graham Leggett wrote: > On 06 Jun 2011, at 11:53 PM, William A. Rowe Jr. wrote: > > I believe the entire fix may be an entry point to > > apr_ldap_parse_uri (check your own binaries to confirm). > > Setting up a single entry point should be trivial, if its > > appropriate. > > This is not so, to fix this, you would need to wrap every single > LDAP API function call[1] in an optional function, and if you did > that, you would solve the problem that caused you to want to > remove apr_ldap from APR in the first place, making the whole > exercise pointless - you may as well just have fixed apr-ldap in > place.
No, that is not correct. You only need to wrap all ap_ldap_* calls and make the depending modules (mod_authnz_ldap, mod_vhost_ldap, ...) link to the ldap libraries themselves. > In it's current form, this change introduces module ordering bugs > to httpd that we haven't suffered for a decade. > > In addition, the autoconf build is currently broken against apr > v1.x on MacOSX, and this is probably broken on other platforms as > well. This introduces serious inconvenience for vendors who have > to mess about trying to make all of this build all over again on > all sorts of platforms. > > The timing cannot be worse - an already suboptimal API plus these > new bugs are being dumped into httpd in the final stages of trying > to bake the final version of httpd v2.4.0, which means we will be > stuck with this brokenness through the life of httpd v2.4. > > There is no need for this move at all, as httpd works perfectly > against APR v1.x (or did until this change). APR v2.x hasn't gone > through any kind of stabilisation phase, never mind seen an alpha > or beta release, and so httpd v2.4.x being compatible with > apr-trunk at this stage is not necessary, especially seeing that > when httpd v2.4 is released, it's API is set in stone, but APR > v2.0's API remains in flux. Or to put it another way, the fact > that apr_ldap is missing from apr-trunk is not a problem for httpd > v2.4, and can be solved after httpd v2.4. Moving the ldap_init code from mod_ldap into apr with httpd 2.2.x broke support for Solaris LDAP (PR 42682), which is a regression from 2.0.x. Fixing that would require changes both in mod_ldap and in apr- ldap. It says a lot that mod_ldap in 2.2.x does not use apr_ldap_init() in the way it is recommended in the documentation (setting secure if ldaps is wanted without client certificates). Because if it did, it would not work, because the apr_ldap code is buggy. Doing these changes in APR 1.x in a way that does not break an unmodified 2.2.x mod_ldap with some LDAP library is next to impossible. So moving the apr_ldap stuff as ap_ldap into httpd and therefore making it possible to change the API is an advantage. > I am therefore vetoing this move of apr_ldap from APR to httpd. Please don't. > We need to focus on getting httpd v2.4 out the door before worrying > about some future version of APR. > > [1] > http://www-archive.mozilla.org/directory/ietf-docs/draft-ietf-ldap > ext-ldap-c-api-05.txt Cheers, Stefan
