Re: [RELEASE CANDIDATE] Apache-Test 1.21
Geoffrey Young wrote: a release candidate for Apache-Test 1.21 is now available. http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz I'm unable to download. I've tried at work and at home without success. I just get a connection timeout error. C:\Documents and Settings\claconslookup cvs.apache.org Server: trinity.dmz.matrix.network Address: 10.10.10.5 Non-authoritative answer: Name:cvs.apache.org Address: 209.237.227.194 Work is behind a proxy. Home is not. -=Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.1.4 available for testing
William A. Rowe, Jr. said: It would be nice if before 2.2 we got around to changing the mod_ldap api to register optional functions. It will still fail to start if the user didn't load mod_ldap, but at least we would accept them loaded in either order. Is this easy to do? /me has yet to learn about optional functions. Regards, Graham --
no results with apr_env_get
Hi folks,
I have a problem getting the environment variables with apr_env_get in
the request handler of my module.
What I need are HTTP_USER_AGENT and REMOTE_ADDRESS but I just don't get
anything as a resullt in my char*.
Here's the code:
8888888--
char* chUserAgent;*
if* (apr_env_get(chUserAgent, HTTP_USER_AGENT, r-pool) == APR_ENOENT) {
ap_rputs( chUserAgent: Kein Eintrag in APR!br\n, r );
}
*else* {
ap_rprintf( r, chUserAgent: %sbr\n , chUserAgent );
}
// I don't even get it using the getenv function:
char *chUserAgent2 = getenv(HTTP_USER_AGENT); ap_rprintf( r,
chUserAgent2 using the getenv() function: %sbr\n, chUserAgent2 );
8888888--
I must have been missing something but I don't know what.
Many thanks for every reply,
yours Henri
iSeries Apache 2.0.x - where is ap_mpm_query equivalent ?
Hi to all, I know there is many IBMers here who track and contribute on this list and while working with Mladen on jk 1.2.8 port for iSeries we saw that ap_mpm_query and AP_MPMQ_MAX_THREADS, used to get the ThreadsPerChild value, was absent from my iSeries V5R2. As such we add the following in mod_jk.c #if APR_HAS_THREADS #ifndef AS400 if (ap_mpm_query(AP_MPMQ_MAX_THREADS, mpm_threads) != APR_SUCCESS) mpm_threads = 1; #endif #endif Now will working on jk 1.2.9 and the ap_mpm_query is still missing. Questions : - First, Did IBM still support Apache 2.0.x on iSeries ? I'm running on 2.0.49 based on my V5R3 dev system and it seems the 2.0.52 is available via PTF. - Did there is a way to get the ThreadsPerChild under iSeries ? - The MPM model on iSeries is worker ? or pod ? Thanks for IBMers clarifications (if they couldn't do it on public lists, I'll be happy to get informations on my private email). Regards
Re: svn commit: r157948 - in httpd/httpd/trunk/srclib/pcre: pcre.c study.c
On Thu, Mar 17, 2005 at 05:50:31PM -, William Rowe wrote: Author: wrowe Date: Thu Mar 17 09:50:29 2005 New Revision: 157948 URL: http://svn.apache.org/viewcvs?view=revrev=157948 Log: Fix three problems with pcre for portability; 1. study.c's pointer arg didn't jive with pcre_fullinfo()'s prototype, however there was no (trivial) way to get them to concur. Cast in this case was the least of several evils. I don't see why this is needed - the last argument to pcre_fullinfo() is void * already, so the cast is surely unnecessary? 2. byteflip had an error for high-bit set bytes, because right shift signed is allowed to extend the sign bit. These had to be unsigned, and the real_pcre types were the safest way to do this. 3. split byteflip into byteflip2/4, to drop size truncation emits, as the arguments are unambigiously 16 or 32 bits as defined in pcre_internal.h. Did you send these upstream to Phil Hazel? ph10 cam.ac.uk Regards, joe
Re: no results with apr_env_get
On Tue, 22 Mar 2005 13:08:04 +0100, Henri Schomäcker [EMAIL PROTECTED] wrote: Hi folks, I have a problem getting the environment variables with apr_env_get in the request handler of my module. What I need are HTTP_USER_AGENT and REMOTE_ADDRESS but I just don't get anything as a resullt in my char*. The Apache environment variables are not available within the Apache process via getenv. Instead, do a lookup in the table r-subprocess_env. If you search through the Apache source code for the string subprocess_env, you'll see numerous examples. Here's one from mod_unique_id: apr_table_get(r-subprocess_env, REDIRECT_UNIQUE_ID)
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
At 06:38 PM 3/21/2005, Justin Erenkrantz wrote: Since moving to Subversion, having apr and apr-util at the same level as httpd is my typical working copy layout, so I'm definitely +1 on this change. srclib/apr and srclib/apr-util don't really make sense anymore, IMO. -- justin Yup, my srclib contains symlinks to apr-1.1 etc. But they are symlinks since my tree containing httpd-2.1, -2.0, -1.3 also contains apr-0.9, 1.0, 1.1 etc. Given than apr-1.0.1 release unpacks as apr-1.0.1 I'm not that comfortable making 'apr' and 'apr-util' path assumptions for the user. I'd be much -more- comfortable assuming ../apr-1 and ../apr-util-1 assumptions. FWIW the old layout didn't work that well under cvs, either. Checkout on a tag tried to inflict the same tag on apr etc. Bill
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
At 11:11 PM 3/21/2005, Paul Querna wrote: Yep, i was tried of passing --with-apr and --with-apr-util to ./buildconf -- this has nothing to do with ./config.nice, and I thought making a ./buildconf.nice would of been a little excessive. Of course! Now I'm on the same page with you. Actually, I believe a buildconf.nice is a better solution (for reasons in my other note.) We really have no say-so about what is sitting in the directory above our httpd snapshot.
Re: svn commit: r125465 httpd/httpd/trunk/modules/ldap/util_ldap.c
Rici Lake wrote: The referenced commit added two OR_ALL directives to util_ldap: LDAPTrustedClientCert LDAPTrustedMode However, that module has no per-directory config struct; all configuration is stored in per-server structs. Consequently, as far as I can see, the OR_ALL directives are unworkable. In particular, LDAPTrustedClientCert, if invoked in an .htaccess file, will: a) store a pointer to request-pool-allocated strings in a config-pool-allocated array b) tromp on changes being made in another thread reading an .htaccess file in the same vhost. Even if it were not for that, it seems odd to me that the configuration merge function appends the parent array of client certs to the current array of client certs; I think that is counter to the idea that a directory might have its own local collection of client certs. (Accumulating the global certs seems more reasonable.) As it stands, if my analysis is correct, the use of LDAPTrustedClientCert in an .htaccess file would probably cause a child to segfault; in a threaded mpm, the consequences would be even more serious. Until a more thorough review is done, it would probably be a good idea to change the directives to RSRC_CONF, or disable them altogether. I am going to change these to RSRC_CONF right now. It is just completely broken to attempt to use the OR_ALL context. Ping to Graham? Can you please take a look at this? -Paul
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
--On Tuesday, March 22, 2005 3:22 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Of course! Now I'm on the same page with you. Actually, I believe a buildconf.nice is a better solution (for reasons in my other note.) We really have no say-so about what is sitting in the directory above our httpd snapshot. It only matters if the directory is present and contains the files we need. I just think a buildconf.nice would be overkill here. -- justin
Re: svn commit: r125465 httpd/httpd/trunk/modules/ldap/util_ldap.c
Paul Querna wrote: The referenced commit added two OR_ALL directives to util_ldap: LDAPTrustedClientCert LDAPTrustedMode However, that module has no per-directory config struct; all configuration is stored in per-server structs. I am going to change these to RSRC_CONF right now. It is just completely broken to attempt to use the OR_ALL context. This is also broken - the LDAPTrustedClientCert is supposed to have scope on a per directory basis. To fix this, we would need to add a directory config creator, and a directory config merger, is that correct? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
buildconf.nice, WAS: Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
Justin Erenkrantz wrote: --On Tuesday, March 22, 2005 3:22 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Of course! Now I'm on the same page with you. Actually, I believe a buildconf.nice is a better solution (for reasons in my other note.) We really have no say-so about what is sitting in the directory above our httpd snapshot. It only matters if the directory is present and contains the files we need. I just think a buildconf.nice would be overkill here. -- justin I find myself agreeing with that... Sander
Re: svn commit: r125465 httpd/httpd/trunk/modules/ldap/util_ldap.c
On 22-Mar-05, at 5:17 PM, Graham Leggett wrote: This is also broken - the LDAPTrustedClientCert is supposed to have scope on a per directory basis. To fix this, we would need to add a directory config creator, and a directory config merger, is that correct? Sure, but then there is still a problem with .htaccess files. The client_certs array will have been allocated in the request pool during the merge operation for the .htaccess file, but it then may be copied into the global connection cache; currently, the code only copies the array header (at line 525). So you'd end up with dangling pointers after the request finished. If, on the other hand, the strings were copied into the server or config pools, then they would slowly consume memory. The most plausible solution might be to manually manage connection cache memory with malloc instead of using pool-allocated memory. Although now that I look at the file again, I see that it never would have worked anyway because at line 1546, the function util_ldap_set_trusted_client_cert stores the certificate in st-global_certs instead of st-client_certs. I also wonder about the two apr_array_append calls at line 1671 in util_ldap_merge_config. The second one would mean that the client certs specified in LDAPTrustedClientCerts would be appended to the list of client certs inherited from some containing section. This might be counter-intuitive if the certs are supposed to be directory scoped. I'm not sure what the use case for this directive would be, so it's hard to know for sure.
Re: svn commit: r125465 httpd/httpd/trunk/modules/ldap/util_ldap.c
Rici Lake wrote: I also wonder about the two apr_array_append calls at line 1671 in util_ldap_merge_config. The second one would mean that the client certs specified in LDAPTrustedClientCerts would be appended to the list of client certs inherited from some containing section. This might be counter-intuitive if the certs are supposed to be directory scoped. I'm not sure what the use case for this directive would be, so it's hard to know for sure. The LDAPTrustedClientCerts directive sets a client certificate (if any) that is valid for LDAP connection attempts within the scope of the directive. There may be a number of different LDAP connection defined in the config, for any number of uses (not just authentication), and each of these can have their own client cert. This looks very broken. Will take a look at it over this weekend, if someone doesn't beat me to it. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
util_ldap.c redux
While I've got util_ldap.c open in front of me, I also noticed that the
following code occurs a number of times:
/*
* If any LDAP operation fails due to LDAP_SERVER_DOWN, control
returns here.
*/
start_over:
if (failures++ 10) {
return result;
}
if (LDAP_SUCCESS != (result = util_ldap_connection_open(r, ldc))) {
return result;
}
// do something with ldc and goto start_over if it returns
LDAP_SERVER_DOWN
Now, util_ldap_connection_open either returns immediately, if the
connection appears to be bound, or it tries to bind the connection,
looping 10 times on LDAP_SERVER_DOWN (line 337, I agree with the
comment at that point in the code).
So in order for the start_over loop to occur more than twice, it would
be necessary that:
some operation returns LDAP_SERVER_DOWN;
util_ldap_connection_open succeeds in reopening the connection
with less than 10 retries;
but the operation returns LDAP_SERVER_DOWN again.
Not only does this seem unlikely, it also seems like a situation where
it would be better to return a 503 than to keep retrying. The correct
logic would be something like:
1. if the connection is bound, try the operation
2. if the operation returns LDAP_SERVER_DOWN or the connection was
not bound,
call util_ldap_connection_open and if it returns success, try the
operation
I'm not sure under what circumstances various LDAP SDKs return
LDAP_SERVER_DOWN, but I suppose it would generally either be because:
1) an existing connection was dropped, perhaps because of an idle
time-out
2) there is no LDAP server listening on the interface at all and
the connection was refused
3) the LDAP server failed to accept the connection within some timeout.
In the first case, one or two retries are in order. In the second case,
retrying is unlikely to change the situation at all. And in the third
case, the user is likely to have long since gone somewhere else. So I
think that 10 retries within connection_open is excessive as well;
three is probably more than enough.
Re: svn commit: r158303 - httpd/httpd/trunk/buildconf
At 04:02 PM 3/22/2005, Justin Erenkrantz wrote: --On Tuesday, March 22, 2005 3:22 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: It only matters if the directory is present and contains the files we need. I just think a buildconf.nice would be overkill here. -- justin Are we certain ../apr/ doesn't contain apr 0.9? If it does, will we proceed with alternatives? If so I can drop my objection, however silly I still think this is :)
Re: svn commit: r125465 httpd/httpd/trunk/modules/ldap/util_ldap.c
At 03:29 PM 3/22/2005, Paul Querna wrote: Rici Lake wrote: The referenced commit added two OR_ALL directives to util_ldap: LDAPTrustedClientCert LDAPTrustedMode I am going to change these to RSRC_CONF right now. It is just completely broken to attempt to use the OR_ALL context. Nope, the correct context would have been OR_AUTHCFG. Now, as far as if we can/should allow these in htaccess is another question. OR_ALL would have introduced a security hole.
Re: 2.1.4 available for testing
At 03:39 AM 3/22/2005, Graham Leggett wrote: William A. Rowe, Jr. said: It would be nice if before 2.2 we got around to changing the mod_ldap api to register optional functions. It will still fail to start if the user didn't load mod_ldap, but at least we would accept them loaded in either order. Is this easy to do? I'd think so. See modules/test/ mod_optional_fn_export.c mod_optional_fn_export.h mod_optional_fn_import.c Optional functions are for many:one implementations mod_optional_hook_export.c mod_optional_hook_export.h mod_optional_hook_import.c Optional hooks are for many:many implementations, where you want multiple backends. These calls seem to be fn's not hooks.
Re: ap_mmn.h Update
Good (autumn) afternoon from Au. Thanks for the reply. If you can get this in the export list as ap_find_child_by_pid it would be very much appreciated! Regards, Norm William A. Rowe, Jr. wrote: Was never explicitly exported and not namespace protected. If you want it re-added, by all means. Just needs ap_ namespace decoration. At 04:18 PM 3/19/2005, NormW wrote: Greetings All, Found the following in ap_mmn.h, but darned if I can find a thread that discusses the reason for its removal or offers an alternate approach; the term 'axed' seems visually aggressive... * 20050217.0 (2.1.3-dev) Axed find_child_by_pid,... Any assistance appreciated, Norm
