Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: > On Tuesday 11 June 2013, André Malo wrote: > > >trunk patch: http://svn.apache.org/r1491155 > > >2.4.x patch: trunk patch works > > >nd: why would you do that in a stable branch? > > > > > > + sf: Because it is only annoying and serves no purpose > > > anymore. If you + want, we can make it a minor MMN bump > > > for adding a "new" API. +1: sf, covener > > > > > >-1: nd > > > > Long discussions in STATUS are kinda tedious ;-) > > > > Well, I think, such changes are what trunk is for. Why not simply > > leave everything below as-is? Even more if it removes only an > > annoyance? Or is there a real technical reason I'm just not seeing > > right now? [...] > > Or, is there a real technical reason to keep it broken in 2.4? Annoying rhetoric games aside - we went from "only annoying" to "broken". What is it now? No other opinion on this? nd
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Wed, 12 Jun 2013 21:18:05 +0200 Stefan Fritsch wrote: > It is a useful function. Disallowing it breaks ISO-C compliant code > for no good reason. There has been a complaint by a module author. > Allowing it does not use any memory because the function is already > in libc. Working around the missing function requires additional > code, which uses memory and may contain bugs. What more reasons do > you need? I'm +1... we should only perform such abuses of stdc / clib within the scope of our own -private- headers. Modifying these in our headers meant for public consumption is a very irritating thing to do. If this were hidden in some CORE_PRIVATE scope then I would have been fine with leaving things as is.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On 14.06.2013 16:41, André Malo wrote: > On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: >> On Tuesday 11 June 2013, André Malo wrote: trunk patch: http://svn.apache.org/r1491155 2.4.x patch: trunk patch works nd: why would you do that in a stable branch? + sf: Because it is only annoying and serves no purpose anymore. If you + want, we can make it a minor MMN bump for adding a "new" API. +1: sf, covener -1: nd >>> >>> Long discussions in STATUS are kinda tedious ;-) >>> >>> Well, I think, such changes are what trunk is for. Why not simply >>> leave everything below as-is? Even more if it removes only an >>> annoyance? Or is there a real technical reason I'm just not seeing >>> right now? > > [...] >> >> Or, is there a real technical reason to keep it broken in 2.4? > > Annoying rhetoric games aside - we went from "only annoying" to "broken". > What > is it now? > > No other opinion on this? As far as I understand the matter, the block removed by the above commit would throw a compiler error if code uses strtoul() and includes httpd.h. The motivation was that at the time the block was introduced some supported platforms, e.g. SunOS 4, did not have strtoul(), so it was helpful to throw that error even when compiled on other platforms to ensure compatibility. The error will also be thrown for any 3rd-party code that uses strtoul() and includes httpd.h when being compiled - so practically all modules are prohibited to use strtoul(). The function is part of C89 which we assume as a minimum when compiling Apache 2.4. So I do not see any positive effects of the old block. I do recognize, that it breaks module compilation for modules using strtoul(). So the proposed change removes an obstacle for full CC89 support in modules. Furthermore I can not imagine any risk of breaking stuff that worked before removing the block. Based on that I am +1 to remove the block. Regards, Rainer
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Fri, Jun 14, 2013 at 10:41 AM, André Malo wrote: > On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: >> On Tuesday 11 June 2013, André Malo wrote: >> > >trunk patch: http://svn.apache.org/r1491155 >> > >2.4.x patch: trunk patch works >> > >nd: why would you do that in a stable branch? >> > > >> > > + sf: Because it is only annoying and serves no purpose >> > > anymore. If you + want, we can make it a minor MMN bump >> > > for adding a "new" API. +1: sf, covener >> > > >> > >-1: nd >> > >> > Long discussions in STATUS are kinda tedious ;-) >> > >> > Well, I think, such changes are what trunk is for. Why not simply >> > leave everything below as-is? Even more if it removes only an >> > annoyance? Or is there a real technical reason I'm just not seeing >> > right now? > > [...] >> >> Or, is there a real technical reason to keep it broken in 2.4? > > Annoying rhetoric games aside - we went from "only annoying" to "broken". What > is it now? > > No other opinion on this? I think Stefan did it justice in the STATUS remark. I don't really understand the objection. Are you afraid a strtoul will sneak into one of our modules, or that a module developer needs this macro to protect them from it? -- Eric Covener cove...@gmail.com
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Friday 14 June 2013 17:34:26 Rainer Jung wrote: > On 14.06.2013 16:41, André Malo wrote: > > On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: > >> On Tuesday 11 June 2013, André Malo wrote: > trunk patch: http://svn.apache.org/r1491155 > 2.4.x patch: trunk patch works > nd: why would you do that in a stable branch? > > + sf: Because it is only annoying and serves no purpose > anymore. If you + want, we can make it a minor MMN bump > for adding a "new" API. +1: sf, covener > > -1: nd > >>> > >>> Long discussions in STATUS are kinda tedious ;-) > >>> > >>> Well, I think, such changes are what trunk is for. Why not simply > >>> leave everything below as-is? Even more if it removes only an > >>> annoyance? Or is there a real technical reason I'm just not seeing > >>> right now? > > > > [...] > > > >> Or, is there a real technical reason to keep it broken in 2.4? > > > > Annoying rhetoric games aside - we went from "only annoying" to "broken". > > What is it now? > > > > No other opinion on this? > > As far as I understand the matter, the block removed by the above commit > would throw a compiler error if code uses strtoul() and includes httpd.h. > > The motivation was that at the time the block was introduced some > supported platforms, e.g. SunOS 4, did not have strtoul(), so it was > helpful to throw that error even when compiled on other platforms to > ensure compatibility. > > The error will also be thrown for any 3rd-party code that uses strtoul() > and includes httpd.h when being compiled - so practically all modules > are prohibited to use strtoul(). > > The function is part of C89 which we assume as a minimum when compiling > Apache 2.4. So I do not see any positive effects of the old block. I do > recognize, that it breaks module compilation for modules using > strtoul(). So the proposed change removes an obstacle for full CC89 > support in modules. Furthermore I can not imagine any risk of breaking > stuff that worked before removing the block. > > Based on that I am +1 to remove the block. I agree, that the block should simply die. However, I question the value of doing cosmetical changes in our stable branches (which is the justification in STATUS). So the question in this specific case is: is it a cosmetical change or not? nd
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013 11:36 AM, "Eric Covener" wrote: > > On Fri, Jun 14, 2013 at 10:41 AM, André Malo wrote: > > On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: > >> On Tuesday 11 June 2013, André Malo wrote: > >> > >trunk patch: http://svn.apache.org/r1491155 > >> > >2.4.x patch: trunk patch works > >> > >nd: why would you do that in a stable branch? > >> > > > >> > > + sf: Because it is only annoying and serves no purpose > >> > > anymore. If you + want, we can make it a minor MMN bump > >> > > for adding a "new" API. +1: sf, covener > >> > > > >> > >-1: nd > >> > > >> > Long discussions in STATUS are kinda tedious ;-) > >> > > >> > Well, I think, such changes are what trunk is for. Why not simply > >> > leave everything below as-is? Even more if it removes only an > >> > annoyance? Or is there a real technical reason I'm just not seeing > >> > right now? > > > > [...] > >> > >> Or, is there a real technical reason to keep it broken in 2.4? > > > > Annoying rhetoric games aside - we went from "only annoying" to "broken". What > > is it now? > > > > No other opinion on this? > > I think Stefan did it justice in the STATUS remark. I don't really > understand the objection. Are you afraid a strtoul will sneak into one > of our modules, or that a module developer needs this macro to protect > them from it? > > -- > Eric Covener > cove...@gmail.com If I can interject randomly... Give it a minor bump so module authors can hide their workarounds for older httpd in a self-documenting way, and so there's a CYA if some very odd, existing module workaround breaks unexpectedly...
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On 14.06.2013 17:44, André Malo wrote: > On Friday 14 June 2013 17:34:26 Rainer Jung wrote: >> On 14.06.2013 16:41, André Malo wrote: >>> On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: On Tuesday 11 June 2013, André Malo wrote: >>trunk patch: http://svn.apache.org/r1491155 >>2.4.x patch: trunk patch works >>nd: why would you do that in a stable branch? >> >> + sf: Because it is only annoying and serves no purpose >> anymore. If you + want, we can make it a minor MMN bump >> for adding a "new" API. +1: sf, covener >> >>-1: nd > > Long discussions in STATUS are kinda tedious ;-) > > Well, I think, such changes are what trunk is for. Why not simply > leave everything below as-is? Even more if it removes only an > annoyance? Or is there a real technical reason I'm just not seeing > right now? >>> >>> [...] >>> Or, is there a real technical reason to keep it broken in 2.4? >>> >>> Annoying rhetoric games aside - we went from "only annoying" to "broken". >>> What is it now? >>> >>> No other opinion on this? >> >> As far as I understand the matter, the block removed by the above commit >> would throw a compiler error if code uses strtoul() and includes httpd.h. >> >> The motivation was that at the time the block was introduced some >> supported platforms, e.g. SunOS 4, did not have strtoul(), so it was >> helpful to throw that error even when compiled on other platforms to >> ensure compatibility. >> >> The error will also be thrown for any 3rd-party code that uses strtoul() >> and includes httpd.h when being compiled - so practically all modules >> are prohibited to use strtoul(). >> >> The function is part of C89 which we assume as a minimum when compiling >> Apache 2.4. So I do not see any positive effects of the old block. I do >> recognize, that it breaks module compilation for modules using >> strtoul(). So the proposed change removes an obstacle for full CC89 >> support in modules. Furthermore I can not imagine any risk of breaking >> stuff that worked before removing the block. >> >> Based on that I am +1 to remove the block. > > I agree, that the block should simply die. However, I question the value of > doing cosmetical changes in our stable branches (which is the justification > in STATUS). > > So the question in this specific case is: is it a cosmetical change or not? We do cosmetical changes in stable branches like e.g. reducing code drift between trunk and 2.4 or fixing typos in comments. We do it if we see only very little risk and anticipate at least some benefit now or for the future. In the case discussed here I'd say the risk is very small and the benefit of a more complete c89 support for module authors is real (but of course not big). I like the addition of the MMN bump suggested by Jeff. Regards, Rainer
AW: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
> -Ursprüngliche Nachricht- > Von: Rainer Jung [] > Gesendet: Freitag, 14. Juni 2013 18:08 > An: dev@httpd.apache.org > Betreff: Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS > > We do cosmetical changes in stable branches like e.g. reducing code > drift between trunk and 2.4 or fixing typos in comments. We do it if we > see only very little risk and anticipate at least some benefit now or > for the future. In the case discussed here I'd say the risk is very > small and the benefit of a more complete c89 support for module authors > is real (but of course not big). I like the addition of the MMN bump > suggested by Jeff. +1 Regards Rüdiger
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013, at 11:44 AM, André Malo wrote: > > I agree, that the block should simply die. However, I question the value of > doing cosmetical changes in our stable branches (which is the justification > in STATUS). > FWIW, I agree. I don't mind such clean-ups and cosmetic changes on trunk, but functional changes (and this is) require a backport proposal.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013, at 12:07 PM, Rainer Jung wrote: > > We do cosmetical changes in stable branches like e.g. reducing code > drift between trunk and 2.4 or fixing typos in comments. Of course. That's not the question (at least IMO). The question is that when a cosmetic change also results in a functional change (and we wouldn't be suggesting MMN bumps if it wasn't), that it becomes a change that should be proposed as a backport and not willy-nilly added. We have a process, and should discourage attempts to bypass it on a stable trunk. FWIW, I'd be +1 with the bump.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
> Of course. That's not the question (at least IMO). The question > is that when a cosmetic change also results in a functional > change (and we wouldn't be suggesting MMN bumps if it wasn't), > that it becomes a change that should be proposed as a backport > and not willy-nilly added. We have a process, and should > discourage attempts to bypass it on a stable trunk. This change followed the process. It currently sits in 2.4.x/STATUS.
Re: svn commit: r1491612 - /httpd/httpd/branches/2.4.x/STATUS
On Jun 14, 2013, at 1:20 PM, Eric Covener wrote: >> Of course. That's not the question (at least IMO). The question >> is that when a cosmetic change also results in a functional >> change (and we wouldn't be suggesting MMN bumps if it wasn't), >> that it becomes a change that should be proposed as a backport >> and not willy-nilly added. We have a process, and should >> discourage attempts to bypass it on a stable trunk. > > This change followed the process. It currently sits in 2.4.x/STATUS. I know... I voted on it :) I was speaking in generalities... sorry for the confusion.
Where is configured the library used by Apache httpd server for the ldap_search_ext_s implementation?
Dear Apache developers! I want to understand where is configured the library used by Apache httpd server for the ldap_search_ext_s implementation. I looked at util_ldap.c: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ldap/util_ldap.c?view=markup result = ldap_search_ext_s(ldc->ldap, (char *)basedn, scope, (char *)filter, attrs, 0, NULL, NULL, NULL, APR_LDAP_SIZELIMIT, &res); The method ldap_search_ext_s can be implemented by different providers, include OpenLDAP, Novell LDAP SDK or iPlanet (Netscape) SDK. Where Apache is configured to use OpenLDAP? Thanks in advance for your help, Michael
Re: Where is configured the library used by Apache httpd server for the ldap_search_ext_s implementation?
On Fri, Jun 14, 2013 at 3:45 PM, Michael Furman wrote: > Dear Apache developers! > > I want to understand where is configured the library used by Apache httpd > server for the ldap_search_ext_s implementation. > > I looked at util_ldap.c: > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ldap/util_ldap.c?view=markup > > result = ldap_search_ext_s(ldc->ldap, > >(char *)basedn, scope, > >(char *)filter, attrs, 0, > >NULL, NULL, NULL, APR_LDAP_SIZELIMIT, &res); > > > > The method ldap_search_ext_s can be implemented by different providers, > include OpenLDAP, Novell LDAP SDK or iPlanet (Netscape) SDK. > The flavor of LDAP SDK is detected when the "apr-util" dependency is configured: srclib/apr-util$ ./configure --help|grep ldap --with-ldap-include=path path to ldap include files with trailing slash --with-ldap-lib=pathpath to ldap lib file --with-ldap=library ldap library to use If you build httpd, apr, and apr-util all at once you usually pass these flags to httpd's configure script and they are passed down to apr-util. For recent releases, You can see the dependency baked into the apr_ldap-1.so using ldd.
RE: Where is configured the library used by Apache httpd server for the ldap_search_ext_s implementation?
Thank you for your reply! I have found the following: ldd /usr/lib64/apr-util-1/apr_ldap-1.so … libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7f337a64d000) … and the following: rpm -ql openldap | grep ".so" ... /lib64/libldap-2.4.so.2 /lib64/libldap-2.4.so.2.5.6 ... I did not find anything related to /etc/httpd/conf/httpd.conf. Should I add libldap-2.4.so.2 or apr_ldap-1.so to the file if I want to use OpenLdap? Or other configuration? Thanks in advance for your help, Michael > Date: Fri, 14 Jun 2013 15:50:56 -0400 > Subject: Re: Where is configured the library used by Apache httpd server for > the ldap_search_ext_s implementation? > From: cove...@gmail.com > To: dev@httpd.apache.org > > On Fri, Jun 14, 2013 at 3:45 PM, Michael Furman > wrote: > > Dear Apache developers! > > > > I want to understand where is configured the library used by Apache httpd > > server for the ldap_search_ext_s implementation. > > > > I looked at util_ldap.c: > > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ldap/util_ldap.c?view=markup > > > > result = ldap_search_ext_s(ldc->ldap, > > > >(char *)basedn, scope, > > > >(char *)filter, attrs, 0, > > > >NULL, NULL, NULL, APR_LDAP_SIZELIMIT, &res); > > > > > > > > The method ldap_search_ext_s can be implemented by different providers, > > include OpenLDAP, Novell LDAP SDK or iPlanet (Netscape) SDK. > > > > The flavor of LDAP SDK is detected when the "apr-util" dependency is > configured: > > srclib/apr-util$ ./configure --help|grep ldap > --with-ldap-include=path path to ldap include files with trailing slash > --with-ldap-lib=pathpath to ldap lib file > --with-ldap=library ldap library to use > > If you build httpd, apr, and apr-util all at once you usually pass > these flags to httpd's configure script and they are passed down to > apr-util. > > For recent releases, You can see the dependency baked into the > apr_ldap-1.so using ldd.
Re: Where is configured the library used by Apache httpd server for the ldap_search_ext_s implementation?
> I did not find anything related to /etc/httpd/conf/httpd.conf. > Should I add libldap-2.4.so.2 or apr_ldap-1.so to the file if I want to use > OpenLdap? I suggest taking the question to us...@httpd.apache.org
Re: svn commit: r1492395 - in /httpd/httpd/trunk: CHANGES modules/aaa/mod_auth_digest.c
On Thursday 13 June 2013, Roy T. Fielding wrote: > On Jun 12, 2013, at 12:34 PM, s...@apache.org wrote: > > Author: sf > > Date: Wed Jun 12 19:34:19 2013 > > New Revision: 1492395 > > > > URL: http://svn.apache.org/r1492395 > > Log: > > Actually use the secret when generating nonces. > > > > This change may cause problems if used with round robin load > > balancers. Before it is backported, we should add a directive to > > use a user specified secret. > > > > PR: 54637 > > FWIW, I don't think this code can be released as is. I agree. That's what I wanted to express in the commit message, sorry if that did not come out correctly. > Using a global pointer to an allocated pool variable is > not even remotely safe when that pool gets deallocated. > And a routine that gets called within .htaccess files is not an > appropriate place to set a server-wide value. It's the process pool, and that won't get cleaned up before server shutdown. And the secret will be initialized in post_config hook at the latest, so there is no chance that it will be called from .htaccess. But moving the whole thing to pre_config would be clearer and better. I will do that when I have some cycles. > because that is where the real fix should be. The current secret > should be replaced here by a configurable string that is set in > the virtual host config. Ack. Though in absence of a configured value, the random secret is fine. Cheers, Stefan
Re: svn commit: r1492395 - in /httpd/httpd/trunk: CHANGES modules/aaa/mod_auth_digest.c
On Friday 14 June 2013, Stefan Fritsch wrote: > > Using a global pointer to an allocated pool variable is > > not even remotely safe when that pool gets deallocated. > > And a routine that gets called within .htaccess files is not an > > appropriate place to set a server-wide value. > > It's the process pool, and that won't get cleaned up before server > shutdown. And the secret will be initialized in post_config hook > at the latest, so there is no chance that it will be called from > .htaccess. But moving the whole thing to pre_config would be > clearer and better. I will do that when I have some cycles. FWIW, I now remember why I did it in this convoluted way. In pre_config, there is no way to get to the process pool. 2.4 has ap_retained_data_* which can be used instead, but in 2.2 it is not that easy. But we can fix that when/if there is actually momentum to backport this to 2.2.
Re: svn commit: r1493247 - /httpd/httpd/branches/2.4.x/STATUS
Hi André, I consider this a new vote and therefore have removed your -1. If you still are -1, please add it to STATUS again. On Friday 14 June 2013, s...@apache.org wrote: > Author: sf > Date: Fri Jun 14 21:07:19 2013 > New Revision: 1493247 > > URL: http://svn.apache.org/r1493247 > Log: > update strtoul proposal to include a minor MMN bump. Keep jim's > conditional vote > > Modified: > httpd/httpd/branches/2.4.x/STATUS
Re: asynch websockets tunnel
On Wed, Jun 12, 2013 at 10:15 AM, Jim Jagielski wrote: > re-looking at this, it would be nice if we could abstract > out the callback itself as simply "some event", where > the callback and the baton itself is self-contained > enuff to define what the event is... eg register_anevent_callback :) FWIW I need to table this for a while if anyone is interested in continuing/morphing it, i won't have any parallel local changes going on. (beginning a tough stretch at work & travel)
Re: asynch websockets tunnel
Anyone opposed if I commit to trunk? On Fri, Jun 14, 2013 at 06:04:36PM -0400, Eric Covener wrote: > On Wed, Jun 12, 2013 at 10:15 AM, Jim Jagielski wrote: > > re-looking at this, it would be nice if we could abstract > > out the callback itself as simply "some event", where > > the callback and the baton itself is self-contained > > enuff to define what the event is... eg register_anevent_callback :) > > FWIW I need to table this for a while if anyone is interested in > continuing/morphing it, i won't have any parallel local changes going > on. > > (beginning a tough stretch at work & travel) -- === Jim Jagielski [|] j...@jagunet.com [|] http://www.jaguNET.com/ "Great is the guilt of an unnecessary war" ~ John Adams
Re: asynch websockets tunnel
On 15 Jun 2013, at 12:40 AM, Jim Jagielski wrote: > Anyone opposed if I commit to trunk? +1 to commit to trunk, that's where this stuff takes shape :) Regards, Graham --
Re: asynch websockets tunnel
On Fri, Jun 14, 2013 at 7:05 PM, Graham Leggett wrote: > On 15 Jun 2013, at 12:40 AM, Jim Jagielski wrote: > >> Anyone opposed if I commit to trunk? > > +1 to commit to trunk, that's where this stuff takes shape :) +1
Re: svn commit: r1492395 - in /httpd/httpd/trunk: CHANGES modules/aaa/mod_auth_digest.c
On Jun 14, 2013, at 2:16 PM, Stefan Fritsch wrote: > On Thursday 13 June 2013, Roy T. Fielding wrote: >> On Jun 12, 2013, at 12:34 PM, s...@apache.org wrote: >>> Author: sf >>> Date: Wed Jun 12 19:34:19 2013 >>> New Revision: 1492395 >>> >>> URL: http://svn.apache.org/r1492395 >>> Log: >>> Actually use the secret when generating nonces. >>> >>> This change may cause problems if used with round robin load >>> balancers. Before it is backported, we should add a directive to >>> use a user specified secret. >>> >>> PR: 54637 >> >> FWIW, I don't think this code can be released as is. > > I agree. That's what I wanted to express in the commit message, sorry > if that did not come out correctly. > > >> Using a global pointer to an allocated pool variable is >> not even remotely safe when that pool gets deallocated. >> And a routine that gets called within .htaccess files is not an >> appropriate place to set a server-wide value. > > It's the process pool, and that won't get cleaned up before server > shutdown. And the secret will be initialized in post_config hook at > the latest, so there is no chance that it will be called from > .htaccess. But moving the whole thing to pre_config would be clearer > and better. I will do that when I have some cycles. The original code did not need access to a pool -- it was a static global array. As near as I can tell, the reason you changed that was just to check to see if it has already been initialized, which can be done easily by making the first byte a non-random, non-zero constant. In spite of the name, this value has almost no need to be secret, so reducing the number of random bytes by one won't matter. >> because that is where the real fix should be. The current secret >> should be replaced here by a configurable string that is set in >> the virtual host config. > > Ack. Though in absence of a configured value, the random secret is > fine. I think it will cause horrible performance issues for any large installation of Digest, such as WebDAV services load-balanced across multiple machines, so I think the fix is worse than the bug. However, I am not confidant that I know enough about this code to object further. The original code seems much more convoluted than it should be, which means either the design is inherently wrong or I simply don't know why it needs to be so complicated. Roy
RE: Where is configured the library used by Apache httpd server for the ldap_search_ext_s implementation?
Thank you for your reply! I hope you will be able answer to one more question (that is fit to dev list and not to users list): According to the link below mod_ldap should be compiled differently for each LDAP SDK (OpenLDAP SDK, Novell LDAP SDK, Mozilla LDAP SDK, native Solaris LDAP SDK or the native Microsoft LDAP SDK): https://httpd.apache.org/docs/current/mod/mod_ldap.html Where can I download mod_ldap for different LDAP SDK (for example for Mozilla LDAP SDK)? Or I should build it on my computer? What is default LDAP SDK that supported by mod_ldap in the httpd distribution. Thanks in advance for your help, Michael > Date: Fri, 14 Jun 2013 15:50:56 -0400 > Subject: Re: Where is configured the library used by Apache httpd server for > the ldap_search_ext_s implementation? > From: cove...@gmail.com > To: dev@httpd.apache.org > > On Fri, Jun 14, 2013 at 3:45 PM, Michael Furman > wrote: > > Dear Apache developers! > > > > I want to understand where is configured the library used by Apache httpd > > server for the ldap_search_ext_s implementation. > > > > I looked at util_ldap.c: > > http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/modules/ldap/util_ldap.c?view=markup > > > > result = ldap_search_ext_s(ldc->ldap, > > > >(char *)basedn, scope, > > > >(char *)filter, attrs, 0, > > > >NULL, NULL, NULL, APR_LDAP_SIZELIMIT, &res); > > > > > > > > The method ldap_search_ext_s can be implemented by different providers, > > include OpenLDAP, Novell LDAP SDK or iPlanet (Netscape) SDK. > > > > The flavor of LDAP SDK is detected when the "apr-util" dependency is > configured: > > srclib/apr-util$ ./configure --help|grep ldap > --with-ldap-include=path path to ldap include files with trailing slash > --with-ldap-lib=pathpath to ldap lib file > --with-ldap=library ldap library to use > > If you build httpd, apr, and apr-util all at once you usually pass > these flags to httpd's configure script and they are passed down to > apr-util. > > For recent releases, You can see the dependency baked into the > apr_ldap-1.so using ldd.
