Re: ldap functions in/to apr
On 7/24/2011 7:36 PM, NormW wrote: >> ldap_memfree >> ldap_msgfree This is assuredly how not to get an API approved. Adding this to apr_ won't happen. By definition, apr_ objects are transactional and pool-bound for their destruction. You should be discussing this with the apr project, the httpd project is already done with this topic.
ldap functions in/to apr
Hi, A build of util_ldap showed 14 function calls that go direct to the NetWare ldap library, and was given a mind that all these needed was adding apr_ to the front and a wrapper in apu. However, discovered that there exists already an apr_ldap_set_option() which is decidedly different from ldap_set_option()... which way ahead? The 'missing' functions (for NetWare anyway): ldap_compare_s ldap_count_entries ldap_err2string ldap_first_entry ldap_get_dn ldap_get_values ldap_memfree ldap_msgfree ldap_parse_result ldap_result ldap_search_ext_s ldap_set_option ldap_simple_bind ldap_unbind_s ldap_value_free Are these the only ones needed? Just these would get NetWare building directly to APU ldap at least. Any others would be a bonus. Regards, Norm
Re: Please test the build
Built this last night against APR/APU 1.4 HEAD, all went well. Thanks Stefan for getting things moving again. Cheers Gregg On 7/24/2011 12:51 PM, Stefan Fritsch wrote: Please test the recent changes of the module selections, especially if you use non-Linux Unix flavors and/or non-default library locations. Don't forget to do ./buildconf first. The ldap revert also affects Windows/Netware. It would be nice if someone could confirm that mod_ldap+mod_authnz_ldap build correctly on these platforms.
Re: Question and request for comments on patch
irective, "1");
+}
+}
+
+return NULL;
+}
+
static const char *set_options(cmd_parms *cmd, void *d_, const char *l)
{
core_dir_config *d = d_;
@@ -3742,6 +3775,9 @@
AP_INIT_RAW_ARGS("AllowOverride", set_override, NULL, ACCESS_CONF,
"Controls what groups of directives can be configured by per-directory "
"config files"),
+AP_INIT_TAKE_ARGV("AllowOverrideList", set_override_list, NULL, ACCESS_CONF,
+ "Controls what individual directives can be configured by per-directory "
+ "config files"),
AP_INIT_RAW_ARGS("Options", set_options, NULL, OR_OPTIONS,
"Set a number of attributes for a given directory"),
AP_INIT_TAKE1("DefaultType", set_default_type, NULL, OR_FILEINFO,
Index: httpd-trunk.AllowOverrideList/server/request.c
===
--- httpd-trunk.AllowOverrideList/server/request.c (revision 1150484)
+++ httpd-trunk.AllowOverrideList/server/request.c (working copy)
@@ -486,6 +486,7 @@
allow_options_t remove;
overrides_t override;
overrides_t override_opts;
+apr_table_t *override_list;
} core_opts_t;
static void core_opts_merge(const ap_conf_vector_t *sec, core_opts_t *opts)
@@ -513,6 +514,11 @@
opts->override = this_dir->override;
opts->override_opts = this_dir->override_opts;
}
+
+ if (this_dir->override_list != NULL) {
+opts->override_list = this_dir->override_list;
+ }
+
}
@@ -740,6 +746,7 @@
opts.remove = this_dir->opts_remove;
opts.override = this_dir->override;
opts.override_opts = this_dir->override_opts;
+opts.override_list = this_dir->override_list;
/* Set aside path_info to merge back onto path_info later.
* If r->filename is a directory, we must remerge the path_info,
@@ -946,12 +953,13 @@
/* No htaccess in an incomplete root path,
* nor if it's disabled
*/
-if (seg < startseg || !opts.override) {
+if (seg < startseg || (!opts.override && opts.override_list ==
NULL)) {
break;
}
+
res = ap_parse_htaccess(&htaccess_conf, r, opts.override,
-opts.override_opts,
+opts.override_opts, opts.override_list,
apr_pstrdup(r->pool, r->filename),
sconf->access_name);
if (res) {
Index: httpd-trunk.AllowOverrideList/include/http_config.h
===
--- httpd-trunk.AllowOverrideList/include/http_config.h (revision 1150484)
+++ httpd-trunk.AllowOverrideList/include/http_config.h (working copy)
@@ -28,6 +28,7 @@
#include "util_cfgtree.h"
#include "ap_config.h"
+#include "apr_tables.h"
#ifdef __cplusplus
extern "C" {
@@ -282,6 +283,8 @@
int override;
/** Which allow-override-opts bits are set */
int override_opts;
+/** Table of directives allowed per AllowOverrideList */
+apr_table_t *override_list;
/** Which methods are <Limit>ed */
apr_int64_t limited;
/** methods which are limited */
@@ -1065,6 +1068,7 @@
* @param r The request currently being served
* @param override Which overrides are active
* @param override_opts Which allow-override-opts bits are set
+ * @param override_list Table of directives allowed for override
* @param path The path to the htaccess file
* @param access_name The list of possible names for .htaccess files
* int The status of the current request
@@ -1073,6 +1077,7 @@
request_rec *r,
int override,
int override_opts,
+ apr_table_t *override_list,
const char *path,
const char *access_name);
Index: httpd-trunk.AllowOverrideList/include/ap_mmn.h
===
--- httpd-trunk.AllowOverrideList/include/ap_mmn.h (revision 1150484)
+++ httpd-trunk.AllowOverrideList/include/ap_mmn.h (working copy)
@@ -342,12 +342,15 @@
* rename AP_EXPR_FLAGS_* -> AP_EXPR_FLAG_*
* 20110702.1 (2.3.14-dev) Add ap_scan_script_header_err*_ex functions
* 20110723.0 (2.3.14-dev) Revert addition of ap_ldap*
+ * 20110724.0 (2.3.14-dev) Add override_list as parameter to ap_parse_htaccess
+ * Add member override_list to cmd_parms_struct,
+ * core_dir_config and htaccess_result
*/
Re: Please test the build
> The ldap revert also affects Windows/Netware. It would be nice if > someone could confirm that mod_ldap+mod_authnz_ldap build correctly on > these platforms. In r1150510 both build fine on Windows. Tested to build x86 with VC9. APR 1.4.5, APU 1.3.9, pcre 8.02 Mario
Re: Please test the build
Hi, NetWare builds httpd-trunk against apr14/apu13 as in days past without any blips, including the LDAP-related pieces. Good job! Norm On 25/07/2011 5:51 AM, Stefan Fritsch wrote: Please test the recent changes of the module selections, especially if you use non-Linux Unix flavors and/or non-default library locations. Don't forget to do ./buildconf first. The ldap revert also affects Windows/Netware. It would be nice if someone could confirm that mod_ldap+mod_authnz_ldap build correctly on these platforms.
Please test the build
Please test the recent changes of the module selections, especially if you use non-Linux Unix flavors and/or non-default library locations. Don't forget to do ./buildconf first. The ldap revert also affects Windows/Netware. It would be nice if someone could confirm that mod_ldap+mod_authnz_ldap build correctly on these platforms.
Re: httpdl.conf: Load mimal list of modules only
I think I have implemented all suggestions from this thread for reallyall/all/most. On Thursday 07 July 2011, Igor Galić wrote: > I agree with Jeff: It would be really good to have only the minimum > list of modules enabled that enable us to support the config we > ship Would it make sense to make the list for 'few' be exactly those modules that are enabled by default? Or do we want 'few' to build more or fewer modules than what is enabled by default? The current list for 'few' is (on Linux with mpm event): mod_access_compat mod_actions mod_alias mod_allowmethods mod_auth_basic mod_auth_form mod_authn_core mod_authn_file mod_authz_core mod_authz_groupfile mod_authz_host mod_authz_user mod_autoindex mod_buffer mod_cgid mod_dir mod_env mod_filter mod_http mod_include mod_log_config mod_mime mod_negotiation mod_ratelimit mod_reqtimeout mod_request mod_setenvif mod_so mod_status mod_unixd mod_userdir mod_version > > on Unix: > > > mod_unixd > mod_mpm_event.so > (or the default mpm that was built) > > mod_authz_host > mod_authz_core > > The following are covered in > dir_module > log_config_module > logio_module > alias_module > cgid_module > mime_module > > Strangely, MIMEMagicFile is not. It is however commented out. > > The following describe the files in extra/ - note I'm not > mentioning mod_authz_core and mod_authz_host, because they > are already indiscrimenatly used in httpd.conf > > multilang-errordoc > == > mod_alias > mod_include > mod_negotiation > > > autoindex > = > mod_autoindex > mod_alias > > languages > = > mod_mime > mod_negotiation > > userdir > === > mod_userdir > > info > > mod_info > mod_status > > manual > == > mod_alias > mod_setenvif > mod_negotiation > > dav > === > mod_alias > mod_auth_digest > mod_authn_core > mod_authn_file > mod_authz_user > mod_dav > mod_dav_fs > > ssl > === > mod_log_config > mod_setenvif > mod_ssl > socache_shmcb_module > > > I think the default list of modules should enable an > administrator to serve up static files without having > to touch the list of modules. Basic auth should also be possible by default, i.e. mod_auth_basic mod_authn_core mod_authn_file mod_authz_user should always be loaded (and not only for dav). The same for redirects (i.e. mod_alias). > > What are the OS specific modules for other platforms? > What's your opinion?
When to install signal handlers
Hi, the Unix MPMs detach from the console in the pre-config hook but install their signal handlers (including the one for SIG_SEGV) only later, in the mpm hook. If a segfault happens in this time period, the segfault will not be visible on the console, won't be reported to the script starting httpd, and won't be logged in the error log. This can be somewhat confusing to users. I have seen this once with a mod_php bug. Does anybody remember if there is a reason why the signal handlers are installed that late? Or can the code simply be moved to the pre-config hook, before detaching? Cheers, Stefan
Re: Limited connectivity
On 7/23/2011 12:50 PM, Stefan Fritsch wrote: > > Sorry for being impatient, but I have now reverted it. You don't seem > to have enough time ATM and I think this was delaying the next beta. Hello Stefan, your assessment was correct... storm damage, work things and family polyopolized my schedule. Thank you for handling this so we can verify the end result and move forward!
Re: Question and request for comments on patch
On Sun, 24 Jul 2011, Stefan Fritsch wrote: and an empty one for some virtual hosts. In the case of an empty list, d->override_list should be set to NULL instead of an empty table for better performance. Well, this would require some additional logic for the config merge. Maybe it's not worth the effort...
Re: Question and request for comments on patch
On Friday 22 July 2011, Daniel Ruggeri wrote: > Attached is the final cut of the patch including doco and MMN bump > as you brought up. I plan to commit this on Monday, time > permitting (and of course in the absence of objections). I'll > cobble something together afterwards for a 2.2 backport. +1 to the principle. This also allows to use LogLevel in .htaccess, which I wanted to implement but never got around to. Some thoughts / nitpicks: style: Include a space between an if and the opening brace. We neee to support C90: core.c: In function 'set_override_list': core.c:1626:5: error: ISO C90 forbids mixed declarations and code [- Werror=declaration-after-statement] When parsing the list, look in ap_config_hash if a directive exists. If not, either log a warning or error out (not sure which is better). I think the word1,word2,... syntax is unwieldly, especially if the list gets long. Maybe use AP_INIT_TAKE_ARGV instead (see e.g. AllowMethods). It should be possible to reset AllowOverrideList to an empty list in a subdir, even if it is set in the parent dir. This is important in the case that there is a permissive AllowOverrideList in main server scope and an empty one for some virtual hosts. In the case of an empty list, d->override_list should be set to NULL instead of an empty table for better performance. Maybe one could allow "disabled" or "reset" as alias for an empty list (like in UserDir/DirectoryIndex). It may be possible that some modules react badly if a directive is used in .htaccess that has previously not been allowed there. For example if the module needs to do some global initialization when a directive is used for the first time. I am not aware of such a case, but it is something we may want to keep in mind if this is backported. And it is definitely something that should go into the new_api_2.4 document.
