Re: Testing
Well, you are already here :) This is the discussion list of the test suite and results folks observe. Whenever you catch a regression, you are welcome to direct the info to dev@httpd.apache.org, noting the prior-good and new-errored flavors of httpd. Beyond that - please submit patches to the perl-framework to this list, and they will be reviewed and committed to the framework. If you have other ideas, we have several test tools, e.g. specweb and so on, and are always willing to entertain more :) Bill At 09:57 PM 8/1/2005, susan philipose wrote: Hi, I would like to join the testing team . I am new to the open source community. Please let me know how can I start with a project. Regards, Susan
Re: Apache2::Cookie odd return values
Lets move this to apreq-dev (at) httpd.apache.org ** Remember to remove modperl@ from the reply list. (mp 2.0.1, libapreq2-2.06-dev, httpd 2.0.51, Fedora Core 2) Not an issue, but httpd 2.0.54 is out since you're using the rest current :) If you haven't time to read below but have some working cookie read/write freeze/thaw code or URLs I'd be grateful! I don't know about freeze/thaw, but I wrote this FAQ :) http://perl.apache.org/docs/2.0/user/coding/cooking.html#Sending_Cookies_Using_libapreq2 (I also tried using APR::Request::Cookie but it seems to be for Apache experts only, quite a confusing interface) HA, I know you're not calling me an apache expert :) Any help gratefully accepted, HTH
R/Apache Integration Project
Hello allo, I'd like to point you to my project, mod_R: The R/Apache Integration Project which depends on libapreq2: http://biostat.mc.vanderbilt.edu/twiki/bin/view/Main/ApacheRproject With the mod_R 0.1.0 distribution, which is licensed under Apache 2.0, I've bundled libapreq 2.0.4. The install has the option of either installing the bundled version or linking to another version already installed. Comments, criticisms welcome. Thanks go to Joe Schaefer for his help spool files and bundling. -- Jeffrey Horner Computer Systems Analyst School of Medicine 615-322-8606 Department of Biostatistics Vanderbilt University
Re: Apache2::Cookie odd return values
Right, I've solved my problem with a hack and some RTFSing, but I think
I've found a bug either in the docs or Apache2::Cookie...
Basically if I read cookies like this:
$cookie_hash_ref = APR::Request::Apache2-handle($r)-jar();
it works, I can treat the return as a hash of cookies.
However, if I (following the Apache2::Cookie man page) go:
$jar=Apache2::Cookie-new($r);
foreach $name ($jar-cookies()){ blah blah }
then the names are actually the full baked header value (eg. name=value)
I have to crack on with my project but I'll leave that one with you.
Phil, thanks for the pointers and the cookie recipes in the FAQ!
John
Re: Apache2::Cookie odd return values
John ORourke [EMAIL PROTECTED] writes:
Right, I've solved my problem with a hack and some RTFSing, but I think
I've found a bug either in the docs or Apache2::Cookie...
Basically if I read cookies like this:
$cookie_hash_ref = APR::Request::Apache2-handle($r)-jar();
it works, I can treat the return as a hash of cookies.
However, if I (following the Apache2::Cookie man page) go:
$jar=Apache2::Cookie-new($r);
foreach $name ($jar-cookies()){ blah blah }
then the names are actually the full baked header value (eg. name=value)
Strangely enough, everything you talk about here is by design.
And it's also why we recommend the new APR::Request:: modules
over Apache2::Cookie and friends, because it's IMO a simpler API.
--
Joe Schaefer
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
On Fri, Jul 22, 2005 at 02:24:50PM +0200, Sander Striker wrote: Joe Orton wrote: On Fri, Jul 22, 2005 at 12:11:56PM -, Martin Kraemer wrote: Author: martin Date: Fri Jul 22 05:11:55 2005 New Revision: 220307 URL: http://svn.apache.org/viewcvs?rev=220307view=rev Log: Allow extraction of the values of SSL certificate extensions into environment variables, so that their value can be used by any module that is aware of environment variables, as in: So what is the point in posting patches for review if you don't actually wait for anyone to review them before committing? That would be my fault. We're here at ApacheCon and when Martin said he posted to the list first I asked him why he didn't commit to trunk directly, since that is C-T-R. It's a reasonable smallish patch, with little impact on existing functionality; hence the nudge. C-T-R is a good way to accumulate a codebase full of unfinished changes if the R bit is ignored by the committer. Ping Martin. http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/[EMAIL PROTECTED] http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/[EMAIL PROTECTED] joe
Re: svn commit: r220307 - in /httpd/httpd/trunk/modules: metadata/mod_setenvif.c ssl/mod_ssl.c ssl/mod_ssl.h ssl/ssl_expr_eval.c
On Tue, Aug 02, 2005 at 12:00:24PM +0100, Joe Orton wrote:
On Fri, Jul 22, 2005 at 02:24:50PM +0200, Sander Striker wrote:
Joe Orton wrote:
On Fri, Jul 22, 2005 at 12:11:56PM -, Martin Kraemer wrote:
Author: martin
Date: Fri Jul 22 05:11:55 2005
New Revision: 220307
URL: http://svn.apache.org/viewcvs?rev=220307view=rev
Log:
Allow extraction of the values of SSL certificate extensions into
environment variables, so that their value can be used by any
module that is aware of environment variables, as in:
So what is the point in posting patches for review if you don't actually
wait for anyone to review them before committing?
That would be my fault. We're here at ApacheCon and when Martin said
he posted to the list first I asked him why he didn't commit to trunk
directly, since that is C-T-R. It's a reasonable smallish patch, with
little impact on existing functionality; hence the nudge.
C-T-R is a good way to accumulate a codebase full of unfinished changes
if the R bit is ignored by the committer. Ping Martin.
http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/[EMAIL
PROTECTED]
http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/[EMAIL
PROTECTED]
http://mail-archives.apache.org/mod_mbox/httpd-dev/200507.mbox/[EMAIL
PROTECTED]
Oops, sorry. Thanks for pinging.
1) this is a pretty specific to way to code it. Is there no way to make
it more general so that OID() is just a function like file() and can be
used e.g. in regex matches too?
The problem with the OID() function is that it where file() (or
another file() like function) return a single value, what OID()
stands for is an array of zero or more values. But there is no
syntax to deal with arrays in place of expressions. I tried to
implement it as function first, but noticed that it would break when
an OID was specified more than once. In the ASF scenario, the
intention is to add multiple extensions with this OID, each one
containing as value a group name of which the client is member.
Because of the pre-existing syntax expr in {value,value}, and
because {value,value} is effectively an array, I chose to implement
the OID() function as a special case of the expr in operator.
Do you have a good idea how to use a function-like syntax, and still
maintain the is an array property?
2) you must always check in the regenerated generated scanner source
along with changes to the lex file.
My bad, sorry for missing that. Committed right now.
3) oid() is a terrible name for this; it's simply the type of the
parameter. It would be like calling malloc() size(). The function
expands (conceptually) to the values of an extension in the peer's
certificate, identified by OID; so call it peerext() or something
meaningful like that.
Good point - Thanks a lot -- that is a *very* good idea, and (if
nobody objects) I'd want to follow this suggestion. I had been a
little unhappy with OID() myself. peerext() is especially good
because it also documents where the certificate came from.
SetEnvIf OID(2.16.840.1.113730.1.13) (.*) Generated (Certificate)
ca=$1
-1 on the naming since OID is completely entirely meaningless in this
context.
In the context of mod_setenvif, I'd even use SSLPeerExt() because
it makes it clear that we are dealing with an SSL-related thing.
Patch mod_setenvif.c.patch attached.
In ssl_peerext.patch there is a patch which changes OID()
to SSLPeerExt() for mod_ssl.
Martin
--
[EMAIL PROTECTED] | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-48332 | 81730 Munich, Germany
Index: ssl_expr.h
===
--- ssl_expr.h (Revision 226989)
+++ ssl_expr.h (Arbeitskopie)
@@ -61,7 +61,7 @@
#endif
typedef enum {
-op_NOP, op_ListElement, op_OidListElement,
+op_NOP, op_ListElement, op_PeerExtElement,
op_True, op_False, op_Not, op_Or, op_And, op_Comp,
op_EQ, op_NE, op_LT, op_LE, op_GT, op_GE, op_IN, op_REG, op_NRE,
op_Digit, op_String, op_Regex, op_Var, op_Func
Index: ssl_expr_eval.c
===
--- ssl_expr_eval.c (Revision 226989)
+++ ssl_expr_eval.c (Arbeitskopie)
@@ -118,7 +118,7 @@
e3 = (ssl_expr *)e2-node_arg1;
e2 = (ssl_expr *)e2-node_arg2;
-if (op == op_OidListElement) {
+if (op == op_PeerExtElement) {
char *w3 = ssl_expr_eval_word(r, e3);
found = ssl_expr_eval_oid(r, w1, w3);
@@ -204,7 +204,7 @@
{
int count = 0, j;
X509 *xs = NULL;
-ASN1_OBJECT *oid;
+ASN1_OBJECT *peerext;
apr_array_header_t *val_array;
SSLConnRec *sslconn = myConnConfig(r-connection);
@@ -212,8 +212,8 @@
if (oidstr == NULL || sslconn == NULL || sslconn-ssl == NULL)
return NULL;
-/* Determine the oid we are looking for */
-if ((oid =
Re: Corrupting error log buffer?
At 12:52 PM 7/25/2005, André Malo wrote: * Akins, Brian wrote: [Mon Jul 25 13:15:28 2005] [error] [client 85.140.27.54] url_cache_handler: may serve STALE content: 0: /toon/tools/img/jewel.jpg, referer: http://schedule.cartoonnetwork.com/servlet/ScheduleServlet?action=showsh owI D=320361show=Justice%20Leaguefilter=tm But, I am not logging from referer on. That shouldn't be there. It's added automatically by the error logging code, if it can be determined. I brought this up before (logging referrer controls the access, not the error log). A possible solution was proposed to allow some sort of formatting for error log 'annotation'. This was a one-off request to the old bug tracking system that was based on the common how did we land here? who sent them to this URL? question. But there are plenty of places that this change to Apache 1.3 and later is nothing but alot of extra noise. Bill
Re: event MPM: async write completion?
Greg Ames wrote: Brian Pane wrote: I'm eager to hear some feedback on this idea: * Will it work? Or am I overlooking some design flaw? it should work as long as everything important that happens after the check_pipeline_flush call still gets done somehow. a quick glance at the code shows that this is mainly logging, scoreboard + event state changes, and getting back into the request loop if appropriate. and of course the rest of the output needs to be written. perhaps the piece of core_output_filter that controls the writing could be broken out into a separate function and called based on a new CONN_STATE. it wouldn't hurt core_output_filter to slim down anyway. Greg
Re: [PATCH] fix util_ldap with older OpenLDAPs
+1 to this fix. Folks, either agree the code is correct, disagree that it should be some other way, identify it's bugs, or hush up. Plenty of people ARE using 2.2 ldap auth today - and there is no reason to stand in the way of committing obvious bug fixes, especially for recently modified code that was just wrong. Once 2.2 has run around the block a few times, most users will pick it up to close such bugs. But this involves reconfiguration, and the users who would appreciate if we would just fix the bug aren't looking to be beta testers. Holding up segfaults as guns to their heads, attempting to force them to 2.1-unstable isn't cool. Bill At 03:59 PM 7/27/2005, Joe Orton wrote: Since 2.0.54, it seems mod_auth_ldap just segfaults on any request if built against older versions of OpenLDAP, 2.2.20 and earlier (pre-2005). It looks like this was another regression caused the addition of the LDAPConnectionTimeout option. (New features, stable branch, regressions? Hmmm, I spot a pattern) http://issues.apache.org/bugzilla/show_bug.cgi?id=34618 mentions this with upgrade OpenLDAP as the solution, which isn't really a great way to give your users that warm fuzzy feeling. Any objections to this? Index: modules/experimental/util_ldap.c === --- modules/experimental/util_ldap.c(revision 225591) +++ modules/experimental/util_ldap.c(working copy) @@ -50,7 +50,21 @@ #define LDAP_CA_TYPE_BASE64 2 #define LDAP_CA_TYPE_CERT7_DB 3 +#if APR_HAS_OPENLDAP_LDAPSDK +#include ldap_features.h +/* LDAP_OPT_NETWORK_TIMEOUT is broken in OpenLDAP 2.2.21, see + * OpenLDAP bug ITS 3487. */ + +#if LDAP_VENDOR_VERSION_MAJOR 2 || \ +(LDAP_VENDOR_VERSION_MAJOR == 2 LDAP_VENDOR_VERSION_MINOR 2) || \ +(LDAP_VENDOR_VERSION_MAJOR == 2 LDAP_VENDOR_VERSION_MINOR == 2 \ + LDAP_VENDOR_VERSION_PATCH 21) +#undef LDAP_OPT_NETWORK_TIMEOUT +#endif + +#endif /* APR_HAS_OPENLDAP_LDAPSDK */ + module AP_MODULE_DECLARE_DATA ldap_module; int util_ldap_handler(request_rec *r);
ETA for 2.0.55?
Hello!. I wonder what is the estimated release date for 2.0.55? Thanks in advance. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://nux.se
Re: [PATCH] fix util_ldap with older OpenLDAPs
William A. Rowe, Jr. said: +1 to this fix. Folks, either agree the code is correct, disagree that it should be some other way, identify it's bugs, or hush up. Plenty of people ARE using 2.2 ldap auth today - and there is no reason to stand in the way of committing obvious bug fixes, especially for recently modified code that was just wrong. I'm not sure where the impression was gained that anybody is standing in the way of fixing bugs in v2.0? I gave it a +1, Joe a +1 by submitting it, and you a +1 above. That's three. Bugs were fixed in v2.2 due to a rewrite that spanned APR v1.1 and httpd, making the fixes neither atomic nor easy to backport. That said, if people want to use v2.0, and if people are keen to fix the remaining bugs in v2.0, then ++1 to that. Patches posted will definitely not be blocked. Regards, Graham --
SSL downloads faster than non SSL?
I decided to do some informal benchmark comparisons between using windows SMBFS and apache/webdav for file transfers. I ended up finding that apache is actually faster at sending files over an SSL connection than a plain connection. I downloaded a ~600 meg test file from the server using windows explorer webfolders, IE, and firefox. Firefox downloads the file in the 4000-5000 KB/s range when using an SSL connection. IE gets over 10,000 KB/s downloading over the secure connection. Both only are able to download at 300-600 KB/s using the non SSL connection though. This is, of course, all done over a 100 Mbps ethernet network that is minimally loaded, and I repeated the test a few times, clearing the browsers caches each time. Needless to say, this is very strange. My client machine is running windows 2000 pro, and the server is running windows 2003 server, with apache 2.0.52 installed. Does anyone have any ideas to possibly explain and correct these results?
Re: SSL downloads faster than non SSL?
Phillip Susi wrote: I decided to do some informal benchmark comparisons between using windows SMBFS and apache/webdav for file transfers. I ended up finding that apache is actually faster at sending files over an SSL connection than a plain connection. I downloaded a ~600 meg test file from the server using windows explorer webfolders, IE, and firefox. Firefox downloads the file in the 4000-5000 KB/s range when using an SSL connection. IE gets over 10,000 KB/s downloading over the secure connection. Both only are able to download at 300-600 KB/s using the non SSL connection though. This is, of course, all done over a 100 Mbps ethernet network that is minimally loaded, and I repeated the test a few times, clearing the browsers caches each time. Did you restart Apache too, to clear the memory cache of the OS? Joost
