New module added: mod_tidy
Hello, A new module has been created and is awaiting approval. If you are a modules.apache.org administrator, please check whether this module passes the requirements of an httpd module and approve it if so. Author: sierkb Module name: mod_tidy Tags:filters License: Apache License 2.0 Homepage:http://mod-tidy.sourceforge.net Caption: A TidyLib based DSO module for the Apache HTTP Server Version 2
URL decoding in Apache module
Hi, I have a C++ filter module written for Apache. I see that all URL's sent to Apache server are encoded. Does Apache already do the URL decoding and store it somewhere in the request_rec structure OR the filter module should explicitly do a URL decoding? If the filter should do the URL decoding then could you please suggest if there are any Apache APR API calls I can make to to the decoding? Thanks a lot.
Re: URL decoding in Apache module
On Fri, Jun 14, 2013 at 9:01 AM, Sindhi Sindhi sindhi@gmail.com wrote: Hi, I have a C++ filter module written for Apache. I see that all URL's sent to Apache server are encoded. Does Apache already do the URL decoding and store it somewhere in the request_rec structure OR the filter module should explicitly do a URL decoding? If the filter should do the URL decoding then could you please suggest if there are any Apache APR API calls I can make to to the decoding? Thanks a lot. http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html#a778f7883e201095a1d914ab7422635eb Cheers Tom
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 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 n...@perlig.de 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 cove...@gmail.com wrote: On Fri, Jun 14, 2013 at 10:41 AM, André Malo n...@perlig.de 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 n...@perlig.de 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 rainer.j...@kippdata.de 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 cove...@gmail.com 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 michael_fur...@hotmail.com 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 michael_fur...@hotmail.com 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 j...@jagunet.com 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 j...@jagunet.com 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 j...@jagunet.com 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 minf...@sharp.fm wrote: On 15 Jun 2013, at 12:40 AM, Jim Jagielski j...@jagunet.com 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 michael_fur...@hotmail.com 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.
