Support for SASL bind in mod_ldap?
Looking at modules/ldap/util_ldap.c , it appears that mod_ldap is hard-wired to support only ldap_simple_bind_s. Has anyone looked into enabling SASL authentication in mod_ldap? Are there any pitfalls I should be cognizant of if I plan to go down that road mysely? --Pete
Re: Support for SASL bind in mod_ldap?
On Thu, Mar 18, 2010 at 10:54 AM, Thomas, Peter ptho...@hpti.com wrote: Looking at modules/ldap/util_ldap.c , it appears that mod_ldap is hard-wired to support only ldap_simple_bind_s. Has anyone looked into enabling SASL authentication in mod_ldap? Are there any pitfalls I should be cognizant of if I plan to go down that road mysely? Just portability between SDKs. -- Eric Covener cove...@gmail.com
Re: svn commit: r924455 - /httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c
On 17.03.2010 21:08, s...@apache.org wrote: Author: sf Date: Wed Mar 17 20:08:42 2010 New Revision: 924455 URL: http://svn.apache.org/viewvc?rev=924455view=rev Log: If the client disconnects and the backend continues to send data fast, forcibly close the backend connection. Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c?rev=924455r1=924454r2=924455view=diff == --- httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c (original) +++ httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c Wed Mar 17 20:08:42 2010 @@ -472,7 +477,10 @@ static int proxy_connect_handler(request * Close the socket and clean up */ -ap_lingering_close(backconn); +if (client_error) +apr_socket_close(sock); Why do we need to close the socket to the client? IMHO this should be done by the regular mechanism. Regards Rüdiger
unsubscribe
Thanks!
Re: unsubscribe
send e-mail to dev-unsubscr...@httpd.apache.org On Thu, Mar 18, 2010 at 11:08 AM, Pranav Bhat dev.pb...@gmail.com wrote: Thanks! -- Born in Roswell... married an alien...
Re: svn commit: r924455 - /httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c
On Thursday 18 March 2010, Ruediger Pluem wrote: On 17.03.2010 21:08, s...@apache.org wrote: Author: sf Date: Wed Mar 17 20:08:42 2010 New Revision: 924455 URL: http://svn.apache.org/viewvc?rev=924455view=rev Log: If the client disconnects and the backend continues to send data fast, forcibly close the backend connection. Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c Modified: httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_ proxy_connect.c?rev=924455r1=924454r2=924455view=diff = = --- httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c (original) +++ httpd/httpd/trunk/modules/proxy/mod_proxy_connect.c Wed Mar 17 20:08:42 2010 @@ -472,7 +477,10 @@ static int proxy_connect_handler(request * Close the socket and clean up */ -ap_lingering_close(backconn); +if (client_error) +apr_socket_close(sock); Why do we need to close the socket to the client? IMHO this should be done by the regular mechanism. This is not the the socket to the client but the socket to the backend. Probably it would be done by the pool cleanup anyway, but the goal is to avioid a lingering close which would just be a waste of bandwidth. Closing the socket explicitly seemed to be the right thing to do.
Question about LoadModule inside VirtualHost container
An Apache server was misconfigured where a LoadModule directive was inside a VirtualHost *:444 definition. I have found a smattering of documentation saying that the LoadModule must be in the server context, not a container context. Assuming is correct, I have a question about what I did observe. My module created a server configuration and initialized it, one flag of which was that the initialization was complete. When a Location directive was hit, the initialized data gets displayed. Here is the oddity: When I hit the Location from anything other than port 444, I would see the initialized data; however, when I hit the Location using port 444, the data was uninitialized. Why? I would expect that the port 444 config block would be the initialized one and every other one would be uninitialized, but I observed the exact opposite. I think that in this case there would be two server config blocks, one for 444 and one in general. Of course, I can find no documentation to explain this, and possibly it needs no explanation, but does anyone have a reasonable idea as to what is going on? I moved the LoadModule outside the virtual container and all works as expected; I simply remain puzzled why it broke backwards. Thank you, Rich Yonts sola fide, sola gratia, solus Christus, sola Scriptura, soli Deo gloria ** * **
RewriteMap vhost with custom settings
Hi all, I've started looking a bit at RewriteMap for a mass vhost deployment however I have some questions around this. In my environment I'm running mod_fcgid + PHP with suexec to limit access for each user, in addition to this I would need to be capable of setting custom paramters for some virtual domains, is this possible using maps or do I get an all or nothing for all vhosts? Thanks /Jonathan
Re: svn commit: r923712 - in /httpd/httpd/trunk/docs/manual: ./ mod/
On Wed, Mar 17, 2010 at 12:17 PM, Noirin Shirley noi...@apache.org wrote: On Wed, Mar 17, 2010 at 12:54 PM, Dan Poirier poir...@pobox.com wrote: How about Apache Web Server? Httpd is just the name of one of the files, and not even the one people run to start it most of the time. Apache HTTP Server is fine, but Apache Web Server is equally correct, easier to pronounce, and less geeky :-) I also like this option. From the peanut gallery, eww. =P +1 to Apache HTTP Server (long name) and httpd (short name). I don't see a compelling reason to rebrand now - we would only want to do so if we wanted to do that as a major 'publicity' push which I doubt is on our collective radar screen. (BTW, the InConSisteNt capitalization always bugged me to no end...) -- justin
