Cryptic error when LWP isn't available
httpd-test gives a really cryptic error message when LWP isn't installed: Use of uninitialized value in concatenation (.) or string at .../Apache-Test/lib/Apache/TestHarness.pm line 121. Be nice if we could fix that. It seems that $_ is trounced by $self-run_t(). My perl-fu doesn't have an elegant solution other than saving $_ before run_t() and then restoring it after. After I did that, I got the 'LWP isn't available' warnings. *light bulb* Once I installed LWP, the error disappeared for whatever reason. Does anyone with perl-fu have a real solution? -- justin
Help understanding the following error
I received the following error on my server and was trying to figure out how to correct it: /usr/local/apache2/bin/httpd: relocation error: /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/APR/ Request/Apache2/Apache2.so: undefined symbol: apreq_handle_apache2 What does it mean? How do I get rid of it? Thanks, Boysenberry boysenberrys.com | habitatlife.com | selfgnosis.com
Re: Debug httpd binaries compiled with --enable-pie with gdb
On Sun, Oct 30, 2005 at 06:47:46PM +0100, Ruediger Pluem wrote: On 10/30/2005 06:29 PM, Justin Erenkrantz wrote: I thought you needed RH-specific patches - that is, no regular (i.e. GNU-stock) version of GDB will support PIE. -- justin There's nothing Red Hat specific about PIE, it's all supported in the upstream toolchain. Thanks for the hint. Meanwhile I downloaded the source RPM of http://rpmfind.net/linux/RPM/fedora/updates/3/x86_64/gdb-6.1post-1.20040607.43.x86_64.html which compiled fine on RHEL 3. But debugging still does not work :-(. I guess the problem now is that my kernel does not give the needed support to gdb as I found something about /proc/PID/auxv it tries to use which is not available on my system. Ah, yeah, there is that too. The PIE stuff was really only introduced in RHEL4 so trying to get this to work on old systems may be hard work. The RHEL4 gdb+kernel can happily debug PIE binaries, anyway. joe
Re: Debug httpd binaries compiled with --enable-pie with gdb
On 11/01/2005 12:53 PM, Joe Orton wrote: On Sun, Oct 30, 2005 at 06:47:46PM +0100, Ruediger Pluem wrote: [..cut..] which compiled fine on RHEL 3. But debugging still does not work :-(. I guess the problem now is that my kernel does not give the needed support to gdb as I found something about /proc/PID/auxv it tries to use which is not available on my system. Ah, yeah, there is that too. The PIE stuff was really only introduced in RHEL4 so trying to get this to work on old systems may be hard work. The RHEL4 gdb+kernel can happily debug PIE binaries, anyway. Ok. So I guess I will continue to work with my PIE binaries on RHEL3 without the possibility to debug them with gdb and will wait for the introduction of RHEL4 in my company to get this fixed. Thanks for feedback. Do you think I should add an hint to the debugging page that RHEL3 + --enable-pie + gdb does not work out of the box? Regards Rüdiger
Re: Debug httpd binaries compiled with --enable-pie with gdb
On Tue, Nov 01, 2005 at 01:05:09PM +0100, Ruediger Pluem wrote: Do you think I should add an hint to the debugging page that RHEL3 + --enable-pie + gdb does not work out of the box? I'll add some text, good idea. joe
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
I wanted to avoid making string copies when possible. Plus, we
don't want to lowercase the URL, since that means /Foo/bar
would be the same as /FOO/Bar, which is wrong :)
Ruediger Pluem wrote:
On 10/31/2005 05:31 PM, [EMAIL PROTECTED] wrote:
Author: jim
Date: Mon Oct 31 08:31:29 2005
New Revision: 329849
URL: http://svn.apache.org/viewcvs?rev=329849view=rev
Log:
Fix a problem where we are doing a case insensitive
match between the worker and the URL. Instead, only
the scheme and hostname are insensitive, the rest
should be case sensitive.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/proxy/proxy_util.c
Thanks for looking into this. I think this is also related to PR36906.
Given the fact that the hostname and the schema already get lowercased by
ap_proxy_add_worker, wouldn't it be faster and clearer to do something like
the following (honest question, I do not know the answer and the best code
should
go in):
PROXY_DECLARE(proxy_worker *) ap_proxy_get_worker(apr_pool_t *p,
proxy_server_conf *conf,
const char *url)
{
proxy_worker *worker;
proxy_worker *max_worker = NULL;
int max_match = 0;
int url_length;
int worker_name_length;
const char *c;
int i;
char *url_copy;
c = ap_strchr_c(url, ':');
if (c == NULL || c[1] != '/' || c[2] != '/' || c[3] == '\0')
return NULL;
url_copy = apr_pstrdup(p, url);
url_length = strlen(url_copy);
/*
* We need to find the start of the path and
* and lowercase all characters before.
*/
c = ap_strchr_c(c+3, '/');
if (c) {
*c = '\0';
ap_str_tolower(url_copy);
*c = '/';
}
else {
ap_str_tolower(url_copy);
}
worker = (proxy_worker *)conf-workers-elts;
/*
* Do a longest match on the worker name to find the worker that
* fits best to the URL.
*/
for (i = 0; i conf-workers-nelts; i++) {
if ( ((worker_name_length = strlen(worker-name)) = url_length)
(worker_name_length max_match)
(strncmp(url_copy, worker-name, worker_name_length) == 0)) {
max_worker = worker;
max_match = worker_name_length;
}
worker++;
}
return max_worker;
}
Regards
Rüdiger
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
Since this happens for each request, doing a string copy seems wasteful to me; it's extra overhead that is avoided with the current impl. Instead, we have an extra assignment and check, which is less expensive. I originally toyed with doing the string copy, but instead opted for a more pointer oriented solution. Ruediger Pluem wrote: On 11/01/2005 02:05 PM, Jim Jagielski wrote: I wanted to avoid making string copies when possible. Plus, we Ok. That was one point of my question as I saw the need to copy the string as a drawback compared to your approach. I was only unsure how much this counts. don't want to lowercase the URL, since that means /Foo/bar would be the same as /FOO/Bar, which is wrong :) Sure, but I actually do not do this. I only lowercase scheme and hostname, because I temporarily terminate my copied string with \0 before I lower case it. So from the functional point of view my approach should do the same as yours. The question was more about which solution - is faster - is more easy to understand if both versions are equally fast Regards Rüdiger [..cut..] -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
On 11/01/2005 02:27 PM, Jim Jagielski wrote: Since this happens for each request, doing a string copy seems wasteful to me; it's extra overhead that is avoided with the current impl. Instead, we have an extra assignment and check, which is less expensive. This is fine. My other approach was born of the idea that we can replace strncasecmp with strncmp in the loop. Just for interest: Any idea regarding the difference in performance between both? Regards Rüdiger [..cut..]
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
Ruediger Pluem wrote: On 11/01/2005 02:27 PM, Jim Jagielski wrote: Since this happens for each request, doing a string copy seems wasteful to me; it's extra overhead that is avoided with the current impl. Instead, we have an extra assignment and check, which is less expensive. This is fine. My other approach was born of the idea that we can replace strncasecmp with strncmp in the loop. Just for interest: Any idea regarding the difference in performance between both? Certainly strncmp is quicker, since strncasecmp does an auto tolower on each char. But we are doing that in both cases, whether we're tolower'ing the string first, or whether we're doing it at comparison time. So we're not saving anything really there. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
On 11/01/2005 02:58 PM, Jim Jagielski wrote: [..cut..] Certainly strncmp is quicker, since strncasecmp does an auto tolower on each char. But we are doing that in both cases, whether we're tolower'ing the string first, or whether we're doing it at comparison time. So we're not saving anything really there. Yes, but lowering explicitly is done *outside* the for loop. strncasecmp is done *inside* the for loop. So we do this via strncasecmp multiple times on the same data. Regards Rüdiger
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
Ruediger Pluem wrote: Certainly strncmp is quicker, since strncasecmp does an auto tolower on each char. But we are doing that in both cases, whether we're tolower'ing the string first, or whether we're doing it at comparison time. So we're not saving anything really there. Yes, but lowering explicitly is done *outside* the for loop. strncasecmp is done *inside* the for loop. So we do this via strncasecmp multiple times on the same data. Whatever. Change it then. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
c = ap_strchr_c(url, ':'); if (c == NULL || c[1] != '/' || c[2] != '/' || c[3] == '\0') return NULL; BTW, unless url is somehow limited to http and ftp, the above is bad code. The proxy should be able to handle arbitrary schemes (eventually), which means requiring scheme://host is bogus. Roy
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
Roy T. Fielding wrote: c = ap_strchr_c(url, ':'); if (c == NULL || c[1] != '/' || c[2] != '/' || c[3] == '\0') return NULL; BTW, unless url is somehow limited to http and ftp, the above is bad code. The proxy should be able to handle arbitrary schemes (eventually), which means requiring scheme://host is bogus. The current code does make that restriction, but yes, it may be too limiting... Of course, this means that the workers would also need to be not so restricted as well :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
Ruediger, would the below appease your sensibilities :)
Index: modules/proxy/proxy_util.c
===
--- modules/proxy/proxy_util.c(revision 329779)
+++ modules/proxy/proxy_util.c(working copy)
@@ -1217,13 +1217,33 @@
int url_length;
int worker_name_length;
const char *c;
+char *url_copy;
int i;
c = ap_strchr_c(url, ':');
if (c == NULL || c[1] != '/' || c[2] != '/' || c[3] == '\0')
return NULL;
+url_copy = apr_pstrdup(p, url);
url_length = strlen(url);
+
+/*
+ * We need to find the start of the path and
+ * therefore we know the length of the scheme://hostname/
+ * part to we can force-lowercase everything up to
+ * the start of the path.
+ */
+c = ap_strchr_c(c+3, '/');
+if (c) {
+char *pathstart;
+pathstart = url_copy + (c - url);
+pathstart = '\0';
+ap_str_tolower(url_copy);
+pathstart = '/';
+} else {
+ap_str_tolower(url_copy);
+}
+
worker = (proxy_worker *)conf-workers-elts;
/*
@@ -1233,7 +1253,7 @@
for (i = 0; i conf-workers-nelts; i++) {
if ( ((worker_name_length = strlen(worker-name)) =
url_length)
(worker_name_length max_match)
-(strncasecmp(url, worker-name, worker_name_length) ==
0) ) {
+(strncmp(url_copy, worker-name, worker_name_length)
== 0) ) {
max_worker = worker;
max_match = worker_name_length;
}
Proxy-Authorization needed for ProxyRemote
proxy_http.c:966
/* XXX: @@@ FIXME: Proxy-Authorization should *only* be
* suppressed if THIS server requested the authentication,
* not when a frontend proxy requested it!
*
* The solution to this problem is probably to strip out
* the Proxy-Authorisation header in the authorisation
* code itself, not here. This saves us having to signal
* somehow whether this request was authenticated or not.
*/
|| !strcasecmp(headers_in[counter].key,Proxy-Authorization)
|| !strcasecmp(headers_in[counter].key,Proxy-Authenticate)) {
I think this code denies any connection to a Forward-Proxy with
Proxy-Authorization even if I try to fake the Proxy-Authorization
Header with mod_headers (RequestHeader).
I know that the Proxy-Authorization Header is a Hop-to-Hop Header
that should be filtered. But the apache is neither able to send a
407 Response nor able to verify the Proxy-Authorization Header.
So I think it would be the best to pass through the Proxy-Authorization
Header.
If this is not possible, it would be nice to have something like
ProxyRemote * http://proxy-user:[EMAIL PROTECTED]
Regards,
Hendrik
--
--
Hendrik Harms
Re: svn commit: r329849 - in /httpd/httpd/trunk: CHANGES modules/proxy/proxy_util.c
On 11/01/2005 04:11 PM, Jim Jagielski wrote: Ruediger, would the below appease your sensibilities :) Yes, it does. I am sorry. I guess I was a little too persistent in this discussion about this patch of comparable limited influence. I did not mean to step on your toes and nerves :-). Regards Rüdiger [..cut..]
Re: [vote] 2.1.9 as beta
söndagen den 30 oktober 2005 05.09 skrev Paul Querna: 2.1.9-Beta is available from: http://people.apache.org/~pquerna/dev/httpd-2.1.9/ Please test and vote on releasing 2.1.9 as BETA. As a reminder, if you know of any issues you consider a SHOW STOPPER for a 2.2.0 stable release, please add them to the branches/2.2.x STATUS file. Thanks, Tested on Mandriva Linux 2006.0 x86_64, works good. I ran the perl-framework from httpd-test, latest from SVN and it only choked on a couple of php tests. t/php/arg.t, t/php/func5.t and t/php/virtual.t. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://nux.se
Re: [vote] 2.1.9 as beta
+1 NetWare Brad On 10/29/2005 at 10:09:46 pm, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: 2.1.9-Beta is available from: http://people.apache.org/~pquerna/dev/httpd-2.1.9/ Please test and vote on releasing 2.1.9 as BETA. As a reminder, if you know of any issues you consider a SHOW STOPPER for a 2.2.0 stable release, please add them to the branches/2.2.x STATUS file. Thanks, Paul
require ldap-attribute
Title: Message I ran into an authentication problem in Apache 2.0.55. I'm trying to use the require ldap-attribute directive and I'm getting an unknown directive error. If I load mod_auth *after* mod_auth_ldap in the conf file, I'm able to authenticate just fine. Is it a bug that mod_auth kills the authorization because it doesn't know what to do with require ldap-attribute? Shouldn't mod_auth let things be and allow other auth modules to try? Location / AuthName "Foobar" AuthType Basic AuthLDAPURL ldap://localhost/ou=people require ldap-attribute foo=bar #require valid-user/Location [Tue Nov 01 15:49:05 2005] [error] [client 132.253.10.114] access to /Windchill failed, reason: unknown require directive:"ldap-attribute sn=admin"[Tue Nov 01 15:49:05 2005] [error] [client 132.253.10.114] access to /Windchill failed, reason: user admin not allowed access
Re: require ldap-attribute
Need to set AuthAuthoritative OFF so that mod_auth allows the authorization to continue. The default is ON. Brad On 11/1/2005 at 3:09:23 pm, in message [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: I ran into an authentication problem in Apache 2.0.55. I'm trying to use the require ldap-attribute directive and I'm getting an unknown directive error. If I load mod_auth *after* mod_auth_ldap in the conf file, I'm able to authenticate just fine. Is it a bug that mod_auth kills the authorization because it doesn't know what to do with require ldap-attribute? Shouldn't mod_auth let things be and allow other auth modules to try? Location / AuthName Foobar AuthType Basic AuthLDAPURL ldap://localhost/ou=people require ldap-attribute foo=bar #require valid-user /Location [Tue Nov 01 15:49:05 2005] [error] [client 132.253.10.114] access to /Windchill failed, reason: unknown require directive:ldap-attribute sn=admin [Tue Nov 01 15:49:05 2005] [error] [client 132.253.10.114] access to /Windchill failed, reason: user admin not allowed access
Re: [vote] 2.1.9 as beta
On Sat, Oct 29, 2005 at 09:09:46PM -0700, Paul Querna wrote: 2.1.9-Beta is available from: http://people.apache.org/~pquerna/dev/httpd-2.1.9/ Please test and vote on releasing 2.1.9 as BETA. +1 for beta. Passes httpd-test on Ubuntu breezy/ppc. -- justin
Re: [vote] 2.1.9 as beta
On Sun, Oct 30, 2005 at 10:14:29AM -0600, William A. Rowe, Jr. wrote: They persist on /trunk/ if anyone wants to revisit them. In the interim, they can simply be blasted on /branches/2.1.x/ - no? Yes, that is the plan I think we agreed on. -- justin
