Re: svn commit: r169535 - /httpd/httpd/branches/1.3.x/src/modules/standard/mod_log_forensic.c
At 11:51 PM 5/10/2005, André Malo wrote: . builds and the old tid:time:pid format is good still on unix. What happend to the good ol' RTC? shrug happy to revert it. mod_log_forensic certainly isn't in the --modules-most list - and was a typical example of an explicitly thread-unsafe module. (statics that never needed to be static? grumf.) I considered this a platform patch from the moment I converted it. I had actually written logic (long gone now after two pool rewrites to APR) which explicitly made the pool memory associated with conf data read-only (to the point of segfaulting the server if the contract was violated.) Essentially 1) it's bad practice and 2) 99% of the time it's an actual bug. Actually I presumed one of the five people on this list that still bother to test 1.3 on a regular basis would comment fairly quickly. I do have a second patch (in just a moment) which applies to the core, which I intended for R-T-C from the get-go. It's a cool idea, not a must-have-to-build. Bill
Modifying Win32 default optimizations?
I'd like to modify the Win32 build projects (of mod_jk, and httpd 1.3/2.0/2.1-dev, along with apr); The /O2 optimization option is extremely agressive, unfortunately it produces less than ideal crash traceback information. That is due to the (implicit) /Oy flag, which omits respecible stack framing. I'd like to change this to /O2 /Oy- to disable this optimization; processing will be unmeasurably slower, but far more useful when crashes do occur. The /O2 optimization also simplifies the stack frame checking for many functions. The /Gs0 option would restore full frame checks, to ensure we don't overflow the stack in the processing of any function. With FirstBill's (wise) choice to reduce the size of our default stack frames within httpd, it seems wise to be extra diligent. However, MS's docs state that /O2 implies /Gs - and I can't determine if that is /Gs0 (implied) or some other behavior. Thoughts from someone with more experience playing in stack probes would be appreciated. All in all - comments? Bill
[patch 1.3] Allow keepalives on bogus requests?
The subject is misleading; we do allow keepalives on any bogus
requests, today. Undoubtedly this is already used in the wild.
Attached is a patch that would drop keepalive for the garbage
requests that never even hit mod_forensics, or any other module,
due to bogus request lines or unparseable header fields.
The argument against, more cycles are wasted in setup and
teardown than simply filtering bogus requests. Counter arguments,
so does the client; and the bogus connection is dumped and a fresh
one created. This actually solved many issues with mod_ssl on
Win32, although it was entirely the wrong solution to the issue
I discovered.
FYI yes in spite of ap_set_keepalive() they still are active. It's
as simple as the fact that the previous request on the connection
is successful, therefore keepalives are alive and well.
Anyways, comments on the patch?
BillIndex: src/main/http_protocol.c
===
--- src/main/http_protocol.c(revision 169530)
+++ src/main/http_protocol.c(working copy)
@@ -1186,6 +1186,7 @@
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
request failed: URI too long);
+r-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1194,6 +1195,7 @@
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
request failed: erroneous characters after protocol
string: %s,
ap_escape_logitem(r-pool, r-the_request));
+r-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1207,6 +1209,7 @@
if (r-status != HTTP_REQUEST_TIME_OUT) {
ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
request failed: error reading the headers);
+r-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
@@ -1260,6 +1263,7 @@
(see RFC2616 section 14.23): %s, r-uri);
}
if (r-status != HTTP_OK) {
+r-keepalive = 0;
ap_send_error_response(r, 0);
ap_log_transaction(r);
return r;
Error in BOOL definition ?
In mod_ssl.h, BOOL
is defined as "unsigned
int".
Some mod_ssl parameters are defined as BOOL:
struct SSLSrvConfigRec
{ SSLModConfigRec
*mc; BOOL
enabled; BOOL
proxy_enabled; const
char *vhost_id;
int
vhost_id_len;
int
session_cache_timeout;
modssl_ctx_t *server;
modssl_ctx_t *proxy; };In
ssl_config.c, the parameters are initialized with UNSET:
sc-enabled
= UNSET;
sc-proxy_enabled =
UNSET;
UNSETis
defined as -1 == signed/unsigned problem
Shouldn't we change the BOOL definition to signed int ?
Rem: On some compilers, BOOLmay be already defined, so the run-time
libraries definition is used instead of mod_ssl one
Re: [1.3 PATCH] rework suppress-error-charset feature
On 5/2/05, Jeff Trawick [EMAIL PROTECTED] wrote: On 5/2/05, Rici Lake [EMAIL PROTECTED] wrote: If the action is required to compensate for a browser bug, wouldn't it be better to leave it as an environment variable and set it with BrowserMatch? You're absolutely right. I put the blinders on to environment variables when I saw that mod_env didn't do anything until the fixup hook, which is too late for processing of Redirect directives. But mod_setenvif does its work sooner and is the proper solution. Funny. I just heard from a Japanese user with an issue with this path too, but this time with 2.0. A third-party module is generating a custom error response and specifies a Japanese codepage in the generated HTML. But it goes through this error response code and picks up the charset=iso-8859-1 attribute. This particular situation isn't tied to a particular browser, but I'll still use the suppress-error-charset solution so that it matches 1.3. The user can use SetEnvIf with Request_URI to match all requests.
Re: Modifying Win32 default optimizations?
William A. Rowe, Jr. wrote: I'd like to modify the Win32 build projects (of mod_jk, and httpd 1.3/2.0/2.1-dev, along with apr); The /O2 optimization option is extremely agressive, unfortunately it produces less than ideal crash traceback information. That is due to the (implicit) /Oy flag, which omits respecible stack framing. I'd like to change this to /O2 /Oy- to disable this optimization; processing will be unmeasurably slower, but far more useful when crashes do occur. The /O2 optimization also simplifies the stack frame checking for many functions. The /Gs0 option would restore full frame checks, to ensure we don't overflow the stack in the processing of any function. With FirstBill's (wise) choice to reduce the size of our default stack frames within httpd, it seems wise to be extra diligent. However, MS's docs state that /O2 implies /Gs - and I can't determine if that is /Gs0 (implied) or some other behavior. Thoughts from someone with more experience playing in stack probes would be appreciated. All in all - comments? Bill +1 in concept. I'll take debugability at the cost of a small performance hit anyday. Bill
Re: [PATCH] SSL patch for ab (ApacheBench)
This is a patch for the version of ab on the trunk.
In this version of ab, HAVE_OPENSSL controls if I
have OpenSSL. I conformed to the way although I
did not checked the case of HAVE_SSLC.
There has also been small more fixes.
1. The resulting shared key bit length is now the
number of effective bits.
2. Now ab does not dump core in case of SSL handshake
error.
Later, I will also submit the above changes for the
original 2.0.54 patch.
--
Masaoki Kobayashi
[EMAIL PROTECTED]
--- ab.c.org2005-05-11 13:32:42.263557000 +0900
+++ ab.c2005-05-11 21:05:19.95778 +0900
@@ -164,6 +164,9 @@
#include sslc.h
#define USE_SSL
#define RSAREF
+#define SK_NUM(x) sk_num(x)
+#define SK_VALUE(x,y) sk_value(x,y)
+typedef STACK X509_STACK_TYPE;
#elif defined(HAVE_OPENSSL)
@@ -176,6 +179,9 @@
#include openssl/ssl.h
#include openssl/rand.h
#define USE_SSL
+#define SK_NUM(x) sk_X509_num(x)
+#define SK_VALUE(x,y) sk_X509_value(x,y)
+typedef STACK_OF(X509) X509_STACK_TYPE;
#endif
@@ -232,9 +238,6 @@
};
struct data {
-#ifdef USE_SSL
-/* insert SSL timings */
-#endif
int read; /* number of bytes read */
apr_time_t starttime; /* start time of connection in seconds since
* Jan. 1, 1970 */
@@ -301,10 +304,11 @@
long epipe = 0; /* number of broken pipe writes */
#ifdef USE_SSL
-int ssl = 0;
-SSL_CTX *ctx;
+int is_ssl;
+SSL_CTX *ssl_ctx;
+char *ssl_cipher = NULL;
+char *ssl_info = NULL;
BIO *bio_out,*bio_err;
-static void write_request(struct connection * c);
#endif
/* store error cases */
@@ -336,7 +340,24 @@
apr_xlate_t *from_ascii, *to_ascii;
#endif
+static void err(char *s);
+static void apr_err(char *s, apr_status_t rv);
+static void write_request(struct connection * c);
+static int compradre(struct data * a, struct data * b);
+static int comprando(struct data * a, struct data * b);
+static int compri(struct data * a, struct data * b);
+static int compwait(struct data * a, struct data * b);
+static void output_results(void);
+static void output_html_results(void);
+static void start_connect(struct connection * c);
static void close_connection(struct connection * c);
+static void read_connection(struct connection * c);
+static void test(void);
+static void copyright(void);
+static void usage(const char *progname);
+static int parse_url(char *url);
+static int open_postfile(const char *pfile);
+
/* - */
/* simple little function to write an error string and exit */
@@ -363,74 +384,6 @@
exit(rv);
}
-#if defined(USE_SSL) USE_THREADS
-/*
- * To ensure thread-safetyness in OpenSSL - work in progress
- */
-
-static apr_thread_mutex_t **lock_cs;
-static int lock_num_locks;
-
-static void ssl_util_thr_lock(int mode, int type,
- const char *file, int line)
-{
-if (type lock_num_locks) {
-if (mode CRYPTO_LOCK) {
-apr_thread_mutex_lock(lock_cs[type]);
-}
-else {
-apr_thread_mutex_unlock(lock_cs[type]);
-}
-}
-}
-
-static unsigned long ssl_util_thr_id(void)
-{
-/* OpenSSL needs this to return an unsigned long. On OS/390, the pthread
- * id is a structure twice that big. Use the TCB pointer instead as a
- * unique unsigned long.
- */
-#ifdef __MVS__
-struct PSA {
-char unmapped[540];
-unsigned long PSATOLD;
-} *psaptr = 0;
-
-return psaptr-PSATOLD;
-#else
-return (unsigned long) apr_os_thread_current();
-#endif
-}
-
-static apr_status_t ssl_util_thread_cleanup(void *data)
-{
-CRYPTO_set_locking_callback(NULL);
-
-/* Let the registered mutex cleanups do their own thing
- */
-return APR_SUCCESS;
-}
-
-void ssl_util_thread_setup(apr_pool_t *p)
-{
-int i;
-
-lock_num_locks = CRYPTO_num_locks();
-lock_cs = apr_palloc(p, lock_num_locks * sizeof(*lock_cs));
-
-for (i = 0; i lock_num_locks; i++) {
-apr_thread_mutex_create((lock_cs[i]), APR_THREAD_MUTEX_DEFAULT, p);
-}
-
-CRYPTO_set_id_callback(ssl_util_thr_id);
-
-CRYPTO_set_locking_callback(ssl_util_thr_lock);
-
-apr_pool_cleanup_register(p, NULL, ssl_util_thread_cleanup,
- apr_pool_cleanup_null);
-}
-#endif
-
/* - */
/* write out request to a connection - assumes we can write
* (small) request out in one go into our new socket buffer
@@ -460,6 +413,24 @@
return(ret);
}
+static void ssl_state_cb(const SSL *s, int w, int r)
+{
+if (w SSL_CB_ALERT) {
+ BIO_printf(bio_err, SSL/TLS Alert [%s] %s:%s\n,
+ (w SSL_CB_READ ? read : write),
+SSL_alert_type_string_long(r),
+SSL_alert_desc_string_long(r));
+} else if (w SSL_CB_LOOP) {
+ BIO_printf(bio_err, SSL/TLS State [%s] %s\n,
+ (SSL_in_connect_init((SSL*)s) ? connect : -),
+
Re: svn commit: r169535 - /httpd/httpd/branches/1.3.x/src/modules/standard/mod_log_forensic.c
On Tue, 10 May 2005 23:36:57 -, [EMAIL PROTECTED] wrote:
[...]
+const char * get_forensic_id(pool *p)
+{
+static APACHE_TLS next_id = 0;
+
+/* we make the assumption that we can't go through all the PIDs in
+ under 1 second */
+#ifdef MULTITHREAD
+return ap_psprintf(p, %x:%lx:%x, getpid(), time(NULL), next_id++);
+#else
+return ap_psprintf(p, %x:%x:%lx:%x, getpid(), gettid(), time(NULL),
next_id++);
+#endif
Isn't the logic backwards here? I'd expect gettid() to be used only if
MULTITHREAD is defined.
This fails to build on OS/2 as there's no gettid(), even though MULTITHREAD
is not defined.
--
__
| Brian Havard | He is not the messiah! |
| [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian |
--
Re: [PATCH] SSL patch for ab (ApacheBench)
This is a second patch to ab in 2.0.54 package.
It fixes the things below against the first patch.
1. The resulting shared key bit length is now the
number of effective bits.
2. Now ab does not dump core in case of SSL handshake
error.
--
Masaoki Kobayashi
[EMAIL PROTECTED]
--- ab.c.org2005-05-08 23:36:00.0 +0900
+++ ab.c2005-05-11 20:47:00.0 +0900
@@ -91,7 +91,7 @@
* ab - or to due to a change in the distribution it is compiled with
* (such as an APR change in for example blocking).
*/
-#define AP_AB_BASEREVISION 2.0.41-dev-ssl-patch
+#define AP_AB_BASEREVISION 2.0.41-dev-ssl-patch-2
/*
* BUGS:
@@ -548,10 +548,10 @@
if (ssl_info == NULL) {
SSL_CIPHER *ci;
X509 *cert;
- int sk_bits, pk_bits;
+ int sk_bits, pk_bits, swork;
ci = SSL_get_current_cipher(c-ssl);
- SSL_CIPHER_get_bits(ci, sk_bits);
+ sk_bits = SSL_CIPHER_get_bits(ci, swork);
cert = SSL_get_peer_certificate(c-ssl);
if (cert)
pk_bits = EVP_PKEY_bits(X509_get_pubkey(cert));
@@ -586,6 +586,7 @@
BIO_printf(bio_err, SSL handshake failed (%d).\n, ecode);
ERR_print_errors(bio_err);
close_connection(c);
+ do_next = 0;
break;
}
}
@@ -723,7 +724,7 @@
printf(Server Hostname:%s\n, hostname);
printf(Server Port:%hd\n, port);
#ifdef AB_USE_SSL
-if (is_ssl)
+if (is_ssl ssl_info)
printf(SSL/TLS Protocol: %s\n, ssl_info);
#endif
printf(\n);
@@ -1697,7 +1698,7 @@
if (!use_html) {
printf(This is ApacheBench, Version %s\n, AP_AB_BASEREVISION
$Revision: 1.121.2.12 $ apache-2.0);
printf(Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd,
http://www.zeustech.net/\n;);
- printf(Copyright (c) 1998-2002 The Apache Software Foundation,
http://www.apache.org/\n;);
+ printf(Copyright (c) 1998-2005 The Apache Software Foundation,
http://www.apache.org/\n;);
printf(\n);
}
else {
Re: [1.3 PATCH] rework suppress-error-charset feature
On 5/11/05, Jeff Trawick [EMAIL PROTECTED] wrote: Funny. I just heard from a Japanese user with an issue with this path too, but this time with 2.0. A third-party module is generating a custom error response and specifies a Japanese codepage in the generated HTML. But it goes through this error response code and picks up the charset=iso-8859-1 attribute. This particular situation isn't tied to a particular browser, but I'll still use the suppress-error-charset solution so that it matches 1.3. The user can use SetEnvIf with Request_URI to match all requests. Not funny: 1.3.x and 2.x docs say that Apache = 2.0.40 already has this feature. I can't find that the trivial code was ever committed though. Related PR: 31274.
Re: Modifying Win32 default optimizations?
VC.NET 2005 (still in Beta 5) has much more optimizations (global nes at link time). Maybe it would be better to go directly to it, no ? - Original Message - From: Branko ibej [EMAIL PROTECTED] To: William A. Rowe, Jr. [EMAIL PROTECTED] Cc: dev@httpd.apache.org; Tomcat Developers List tomcat-dev@jakarta.apache.org; dev@apr.apache.org Sent: Wednesday, May 11, 2005 3:46 PM Subject: Re: Modifying Win32 default optimizations? William A. Rowe, Jr. wrote: I'd like to modify the Win32 build projects (of mod_jk, and httpd 1.3/2.0/2.1-dev, along with apr); The /O2 optimization option is extremely agressive, unfortunately it produces less than ideal crash traceback information. That is due to the (implicit) /Oy flag, which omits respecible stack framing. I'd like to change this to /O2 /Oy- to disable this optimization; processing will be unmeasurably slower, but far more useful when crashes do occur. Well, unmeasurably is obviously wrong :) But yes, I don't think an extra cycle per non-inlined function call would show up all that much. The /O2 optimization also simplifies the stack frame checking for many functions. The /Gs0 option would restore full frame checks, to ensure we don't overflow the stack in the processing of any function. With FirstBill's (wise) choice to reduce the size of our default stack frames within httpd, it seems wise to be extra diligent. However, MS's docs state that /O2 implies /Gs - and I can't determine if that is /Gs0 (implied) or some other behavior. Thoughts from someone with more experience playing in stack probes would be appreciated. /Gs0 is a bad idea, IMHO, because it only makes sense if you write your own stack probe routine. The default /Gs will probe a page at a time, which works well with NT's virtual memory manager, and still makes the stack grow enough. All in all - comments? How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? It's time, to say the least. -- Brane
Re: svn commit: r169535 - /httpd/httpd/branches/1.3.x/src/modules/standard/mod_log_forensic.c
At 08:39 AM 5/11/2005, Brian Havard wrote: On Tue, 10 May 2005 23:36:57 -, [EMAIL PROTECTED] wrote: +#ifdef MULTITHREAD +return ap_psprintf(p, %x:%lx:%x, getpid(), time(NULL), next_id++); +#else +return ap_psprintf(p, %x:%x:%lx:%x, getpid(), gettid(), time(NULL), next_id++); +#endif Isn't the logic backwards here? I'd expect gettid() to be used only if MULTITHREAD is defined. Yes, now fixed in branches/1.3.x/ - thank you.
Re: Modifying Win32 default optimizations?
[EMAIL PROTECTED] wrote: VC.NET 2005 (still in Beta 5) still in beta... has much more optimizations (global nes at link time). Maybe it would be better to go directly to it, no ? 99% of the work of moving from MSVC6 to any flavour of VC.Net is in converting the project files. So it doesn't matter if the target is 2003 or 2005. -- Brane
Re: Modifying Win32 default optimizations?
William A. Rowe, Jr. wrote: I'd like to modify the Win32 build projects (of mod_jk, and httpd 1.3/2.0/2.1-dev, along with apr); The /O2 optimization option is extremely agressive, unfortunately it produces less than ideal crash traceback information. That is due to the (implicit) /Oy flag, which omits respecible stack framing. I'd like to change this to /O2 /Oy- to disable this optimization; processing will be unmeasurably slower, but far more useful when crashes do occur. Well, unmeasurably is obviously wrong :) But yes, I don't think an extra cycle per non-inlined function call would show up all that much. The /O2 optimization also simplifies the stack frame checking for many functions. The /Gs0 option would restore full frame checks, to ensure we don't overflow the stack in the processing of any function. With FirstBill's (wise) choice to reduce the size of our default stack frames within httpd, it seems wise to be extra diligent. However, MS's docs state that /O2 implies /Gs - and I can't determine if that is /Gs0 (implied) or some other behavior. Thoughts from someone with more experience playing in stack probes would be appreciated. /Gs0 is a bad idea, IMHO, because it only makes sense if you write your own stack probe routine. The default /Gs will probe a page at a time, which works well with NT's virtual memory manager, and still makes the stack grow enough. All in all - comments? How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? It's time, to say the least. -- Brane
Re: Modifying Win32 default optimizations?
William A. Rowe, Jr. wrote: At 08:46 AM 5/11/2005, Branko ibej wrote: All in all - comments? How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? It's time, to say the least. Not for 1.3 or 2.0 httpd - you lose some measure of binary compatibility. We can jump through hoops to continue to use the msvcrt.dll but it's suboptimal. To pick up msvcr70.dll will cause some measure of pain. I'm willing to consider moving to Visual C 7 for binary builds of httpd-2.1+ if enough of the community is behind it. For that matter, perhaps its time to drop Win9x support from httpd-2.1+ (?) Yes, please. Win9* belongs on the junk heap of history. Bill
Re: Modifying Win32 default optimizations?
At 08:46 AM 5/11/2005, Branko Čibej wrote: All in all - comments? How about moving away from MSVC 6 to (say) VC.Net 2003, while we're at it? It's time, to say the least. Not for 1.3 or 2.0 httpd - you lose some measure of binary compatibility. We can jump through hoops to continue to use the msvcrt.dll but it's suboptimal. To pick up msvcr70.dll will cause some measure of pain. I'm willing to consider moving to Visual C 7 for binary builds of httpd-2.1+ if enough of the community is behind it. For that matter, perhaps its time to drop Win9x support from httpd-2.1+ (?) If your thought is no - lots of people still use 9x - then also consider that lots of people are quite happy with their VC 5 or 6 and it just continues to work for them. Here's an example of the issue; http://mail.gnome.org/archives/dia-list/2003-March/msg00141.html Nothing stops YOU today from using VC7, in fact VisualStudio will gladly parse the .dsp files into .vcproc's, .dsw into .sln. The question, rather, is what clib and compiler to use to create the binary distributions - and right now, We obviously want users to be able to elect /GS compilation under VC7 for stack guard sentinels. If the open source community tends to push back on Microsoft's newest compilers, it's simply because their forced treadmill is the anathema of inclusiveness. At 10:45 AM 5/11/2005, Branko Čibej wrote: 99% of the work of moving from MSVC6 to any flavour of VC.Net is in converting the project files. So it doesn't matter if the target is 2003 or 2005. That would be 1% of the work. Visual Studio.NET does that work for you. Bill
Re: Modifying Win32 default optimizations?
William A. Rowe, Jr. wrote: If the open source community tends to push back on Microsoft's newest compilers, it's simply because their forced treadmill is the anathema of inclusiveness. That's what's happening right now with Subversion. The Python 2.4 distro is built with VS.NET (2003, I think). HTTPD is built with MSVC 6. Subversion tries to link with both. So right now, we're stuck with either providing only Python 2.3 bindings, or not being able to use an HTTPD from the apache.org installer... -- Brane
Re: Modifying Win32 default optimizations?
At 04:35 PM 5/11/2005, Branko Čibej wrote: William A. Rowe, Jr. wrote: If the open source community tends to push back on Microsoft's newest compilers, it's simply because their forced treadmill is the anathema of inclusiveness. That's what's happening right now with Subversion. The Python 2.4 distro is built with VS.NET (2003, I think). HTTPD is built with MSVC 6. Subversion tries to link with both. So right now, we're stuck with either providing only Python 2.3 bindings, or not being able to use an HTTPD from the apache.org installer... Yes - I see Python 2.3 / Mod Perl 5.8 / Apache 2.0 / APR 0.9 / etc all in the same 'generation' of code. Do you want the ASF to be a leader of this 'breakage' as the Python project was? This is why the push back. And I hope for Python 2.4 / Apache 2.2 / APR 2.0 / etc to all be of the next 'generation', finally adopting msvcr70. Seem rational?
Re: Modifying Win32 default optimizations?
William A. Rowe, Jr. wrote: At 04:35 PM 5/11/2005, Branko ibej wrote: William A. Rowe, Jr. wrote: If the open source community tends to push back on Microsoft's newest compilers, it's simply because their forced treadmill is the anathema of inclusiveness. That's what's happening right now with Subversion. The Python 2.4 distro is built with VS.NET (2003, I think). HTTPD is built with MSVC 6. Subversion tries to link with both. So right now, we're stuck with either providing only Python 2.3 bindings, or not being able to use an HTTPD from the apache.org installer... Yes - I see Python 2.3 / Mod Perl 5.8 / Apache 2.0 / APR 0.9 / etc all in the same 'generation' of code. Do you want the ASF to be a leader of this 'breakage' as the Python project was? This is why the push back. And I hope for Python 2.4 / Apache 2.2 / APR 2.0 / etc to all be of the next 'generation', finally adopting msvcr70. Seem rational? I can live with that. -- Brane
Re: need a custom verify_resp function
Hello all, I have a change which implements a generic function comparing returned code against specified as an attribute of the url. The diff is enclosed. Is there a document how to check-in into the flood source tree? Yup. It is actually for httpd-dev folks, but most rules apply anyway: http://httpd.apache.org/dev/patches.html Before you prepare unified diff (see document above), I'd suggest removing global waitfor (flood_round_robin.c). It doesn't seem to be used anywhere else. Also please consider using 'acceptcode' in favor of 'waitfor'. Technically speaking, flood doesn't wait for anything. It just chceks return code, and moves forward. Besides that looks OK. If nobody has any objections, I'll commit it as soon as I get my development machine ready. regards, -- Jacek Prucia
Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
[EMAIL PROTECTED] wrote: Author: bnicholes Date: Wed May 11 15:34:18 2005 New Revision: 169705 URL: http://svn.apache.org/viewcvs?rev=169705view=rev Log: Add the LDAPVerifyServerCert directive to util_ldap to force verification of a server certificate when establishing an SSL connection to the LDAP server Modified: httpd/httpd/trunk/include/util_ldap.h httpd/httpd/trunk/modules/ldap/util_ldap.c Ack. This commit means that httpd/trunk now depends on apr-util/trunk. Before this you were able to run httpd/trunk using APR-Util 1.1.x. This effectively kills any httpd alphas until APR-Util 1.2.0 is released. I believe we should uphold the policy of using only released versions of a dependency. I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could still use more love. This is just an example of why I wanted to branch trunk to 2.1.x. I have nothing against adding this specific feature -- it just happens to require a non-released version of APR-Util. Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0? Thanks, -Paul
Reverting vs branching, WAS: Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
Paul Querna wrote: [EMAIL PROTECTED] wrote: Author: bnicholes Date: Wed May 11 15:34:18 2005 New Revision: 169705 URL: http://svn.apache.org/viewcvs?rev=169705view=rev Log: Add the LDAPVerifyServerCert directive to util_ldap to force verification of a server certificate when establishing an SSL connection to the LDAP server Modified: httpd/httpd/trunk/include/util_ldap.h httpd/httpd/trunk/modules/ldap/util_ldap.c Ack. This commit means that httpd/trunk now depends on apr-util/trunk. Before this you were able to run httpd/trunk using APR-Util 1.1.x. Which is a no-go. Please revert. This effectively kills any httpd alphas until APR-Util 1.2.0 is released. I believe we should uphold the policy of using only released versions of a dependency. +1. I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could still use more love. This is just an example of why I wanted to branch trunk to 2.1.x. I have nothing against adding this specific feature -- it just happens to require a non-released version of APR-Util. Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0? Yes. We could do the branch... Sander
Re: Reverting vs branching, WAS: Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
Sander Striker wrote: Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0? Yes. We could do the branch... Heck, you don't even need to revert the commit to do that, just branch from the revision before the change was made to trunk... -garrett
Re: [ANNOUNCE] libapreq2-2.05-dev Released
Quoting Bojan Smojver [EMAIL PROTECTED]: Quoting [EMAIL PROTECTED]: libapreq2-2.05-dev Released I will make libapreq2 and accompanying (e.g. mod_perl 2.0.0-RC6) RPMS for Fedora Core 3 available in the next day or so. The (untested) RPMS are here: ftp://ftp.rexursive.com/pub/libapreq2/ You will probably need mod_perl 2.0.0-RC6 too: ftp://ftp.rexursive.com/pub/mod-perl/ Note that you may be required to download a few other required RPMS. They should be in the first location. If anything breaks, let me know. -- Bojan
Re: Reverting vs branching, WAS: Re: svn commit: r169705 - in /httpd/httpd/trunk:include/util_ldap.h
Sorry, wasn't thinking about apr-util 1.1.x compatibility. Which would you rather see happen, revert or branch without this change? How soon are we going to see apr-util 1.2? Without this directive, certificate verification is at the mercy of the global ldap setting. Brad [EMAIL PROTECTED] Wednesday, May 11, 2005 4:57:24 PM Sander Striker wrote: Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0? Yes. We could do the branch... Heck, you don't even need to revert the commit to do that, just branch from the revision before the change was made to trunk... -garrett
Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
At 05:52 PM 5/11/2005, Paul Querna wrote: I believe we should uphold the policy of using only released versions of a dependency. +1, however... I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could still use more love. Why not? Looks like apr_dbd should simply be pushed off to apr_util release 1.3.0 and get the other fixes and features out the door, perhaps. This is just an example of why I wanted to branch trunk to 2.1.x. I have nothing against adding this specific feature -- it just happens to require a non-released version of APR-Util. -1 for this specific purpose; I always saw httpd-2.2 as addressing only the handful of things we never did quite finish in 2.0. Those being the auth reorg, auth ldap, proxy and cache. If httpd-2.2 can really be boiled down to this small subset - I would very much like to see this work adopted. If it means creating a dbd-less apr_util 1.2.0 then so be it. Thoughts? Bill
Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
Is there an issue with backporting this change to 1.1.x branch and releasing a apr-util 1.1.3? Brad [EMAIL PROTECTED] Wednesday, May 11, 2005 5:28:19 PM At 05:52 PM 5/11/2005, Paul Querna wrote: I believe we should uphold the policy of using only released versions of a dependency. +1, however... I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could still use more love. Why not? Looks like apr_dbd should simply be pushed off to apr_util release 1.3.0 and get the other fixes and features out the door, perhaps. This is just an example of why I wanted to branch trunk to 2.1.x. I have nothing against adding this specific feature -- it just happens to require a non-released version of APR-Util. -1 for this specific purpose; I always saw httpd-2.2 as addressing only the handful of things we never did quite finish in 2.0. Those being the auth reorg, auth ldap, proxy and cache. If httpd-2.2 can really be boiled down to this small subset - I would very much like to see this work adopted. If it means creating a dbd-less apr_util 1.2.0 then so be it. Thoughts? Bill
Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
Brad Nicholes wrote: Is there an issue with backporting this change to 1.1.x branch and releasing a apr-util 1.1.3? Yes, According to APR's versioning policy: http://apr.apache.org/versioning.html Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards. Since 1.1.3 would be a PATCH version, you cannot add a new symbol, since this would break both binary and source backwards compat. The first version that could contain this new symbol is 1.2.0. Since APR/APR-Util are still very closely tied to HTTPD, I think we can justify releasing APR more often. -Paul [EMAIL PROTECTED] Wednesday, May 11, 2005 5:28:19 PM At 05:52 PM 5/11/2005, Paul Querna wrote: I believe we should uphold the policy of using only released versions of a dependency. +1, however... I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could still use more love. Why not? Looks like apr_dbd should simply be pushed off to apr_util release 1.3.0 and get the other fixes and features out the door, perhaps. This is just an example of why I wanted to branch trunk to 2.1.x. I have nothing against adding this specific feature -- it just happens to require a non-released version of APR-Util. -1 for this specific purpose; I always saw httpd-2.2 as addressing only the handful of things we never did quite finish in 2.0. Those being the auth reorg, auth ldap, proxy and cache. If httpd-2.2 can really be boiled down to this small subset - I would very much like to see this work adopted. If it means creating a dbd-less apr_util 1.2.0 then so be it. Thoughts? Bill
Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c
At 06:43 PM 5/11/2005, Brad Nicholes wrote: Is there an issue with backporting this change to 1.1.x branch and releasing a apr-util 1.1.3? Yes, IIUC we don't add API features on the subversion bumps, only on minor version bumps. So this new option triggers an automatic minor bump to 1.2.0 (so does apr_dbd).
Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.hmodules/ldap/util_ldap.c
So I guess I am confused. Are you saying that we *can* release 1.2 or am I stuck with putting LDAP SDK #ifdef code back in util_ldap in order to fix this problem? Brad [EMAIL PROTECTED] Wednesday, May 11, 2005 5:56 PM Brad Nicholes wrote: Is there an issue with backporting this change to 1.1.x branch and releasing a apr-util 1.1.3? Yes, According to APR's versioning policy: http://apr.apache.org/versioning.html Versions are denoted using a standard triplet of integers: MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are incompatible, large-scale upgrades of the API. MINOR versions retain source and binary compatibility with older minor versions, and changes in the PATCH level are perfectly compatible, forwards and backwards. Since 1.1.3 would be a PATCH version, you cannot add a new symbol, since this would break both binary and source backwards compat. The first version that could contain this new symbol is 1.2.0. Since APR/APR-Util are still very closely tied to HTTPD, I think we can justify releasing APR more often. -Paul [EMAIL PROTECTED] Wednesday, May 11, 2005 5:28:19 PM At 05:52 PM 5/11/2005, Paul Querna wrote: I believe we should uphold the policy of using only released versions of a dependency. +1, however... I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could still use more love. Why not? Looks like apr_dbd should simply be pushed off to apr_util release 1.3.0 and get the other fixes and features out the door, perhaps. This is just an example of why I wanted to branch trunk to 2.1.x. I have nothing against adding this specific feature -- it just happens to require a non-released version of APR-Util. -1 for this specific purpose; I always saw httpd-2.2 as addressing only the handful of things we never did quite finish in 2.0. Those being the auth reorg, auth ldap, proxy and cache. If httpd-2.2 can really be boiled down to this small subset - I would very much like to see this work adopted. If it means creating a dbd-less apr_util 1.2.0 then so be it. Thoughts? Bill
Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.hmodules/ldap/util_ldap.c
Brad Nicholes wrote: So I guess I am confused. Are you saying that we *can* release 1.2 or am I stuck with putting LDAP SDK #ifdef code back in util_ldap in order to fix this problem? I am saying we can release APR-Util 1.2 -- but that discussion belongs on apr-dev. I think the best solution right now is to #ifdef it. I don't think it should be reverted. The point of trunk is to always be open for commits and new development.
Re: Modifying Win32 default optimizations?
On Thu, 12 May 2005, Branko ^Libej wrote: William A. Rowe, Jr. wrote: [ ... ] Yes - I see Python 2.3 / Mod Perl 5.8 / Apache 2.0 / APR 0.9 / etc all in the same 'generation' of code. Do you want the ASF to be a leader of this 'breakage' as the Python project was? This is why the push back. And I hope for Python 2.4 / Apache 2.2 / APR 2.0 / etc to all be of the next 'generation', finally adopting msvcr70. Seem rational? I can live with that. That sounds great, but one consideration from the point of view of Perl (eg, mod_perl) is that the dominant Win32 Perl binary, from ActiveState, uses VC 6 to compile, and they don't have any plans soon of changing that. But that might change by the next generation. -- best regards, randy kobes
[VOTE] 2.2.0 Alpha on Friday
Based on the results from the '[PROPOSAL] Branch 2.1.x on May 13', there are enough positive votes create the 2.1.x branch on this Friday: +1: justin, Brad, Sander, (me) -1: wrowe +1, but latter discussed problems: Jim Instead of calling it branches/2.1.x, on IRC wrowe suggested going straight to branches/2.2.x, and on further thought I agree. There is little point is calling it 2.1.x, if its only purpose is to become 2.2.x. If we really want to move forward towards GA, we should just start on 2.2.x releases, and use the standard -alpha, and -beta names on the tarbals, until one is good enough for GA. I doubt that the first alpha will be perfect, but the version numbers are cheap. My intention is to roll 2.2.0-alpha on Friday or early Saturday, after copying trunk to branches/2.2.x. This is different from the original details of the '[PROPOSAL] Branch 2.1.x on May 13' thread, but the result is the same. Votes on going straight to 2.2.0-alpha?
[VOTE] Commit Policy on 2.2.x
I propose the following policy apply to the 2.2.x branch, once (and if) it is created: Before GA: A 'soft' CTR. Any small bug fixes can be directly committed. Any API changes must be reviewed by the list. (lazy consensus). Any large changes must get voted on. After first GA: Standard RTC, as done on 2.0.x.
Problem with -path in Apache2::Cookie?
Hi, I've been playing around with Apache2::Cookie and I've found that when setting -path via my $cookie = Apache2::Cookie-new($r, -path = $mypath...) # I also set -name, -value, -expires, -domain, -secure the same way ends up setting -path to 'domain' when I view the cookie, regardless of the value of $mypath. This doesn't seem to affect firefox but IE has some issues with it. However if I set -path via mutator such as $cookie-path($mypath), the path value in the cookie is set correctly. Has anyone else run into this? I'm using dev_2_05. Thanks, Fred
Re: Modifying Win32 default optimizations?
At 08:29 PM 5/11/2005, Randy Kobes wrote: That sounds great, but one consideration from the point of view of Perl (eg, mod_perl) is that the dominant Win32 Perl binary, from ActiveState, uses VC 6 to compile, and they don't have any plans soon of changing that. But that might change by the next generation. There is yet another consideration which might kill this entire discussion. The beta VC++ 2005 Express includes everything one would want, nmake, cl, lib, link et al. It does not have msvcr70.lib in it's lib/ tree. It does have msvcrt.lib. In SDK\v2.0\Bin one also finds msvcr80.dll. Which means, it appears, that msvcr70.dll never 'arrived' and has been orphaned. Perhaps ActiveState took a better route with Perl than Python. Bill
[STATUS] (httpd-2.0) Wed May 11 23:46:21 2005
APACHE 2.0 STATUS: -*-text-*-
Last modified at [$Date: 2005-05-06 11:22:51 -0400 (Fri, 06 May 2005) $]
The current version of this file can be found at:
http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS
Release history:
2.0.55 : in development
2.0.54 : released April 17, 2005 as GA.
2.0.53 : released February 7, 2005 as GA.
2.0.52 : released September 28, 2004 as GA.
2.0.51 : released September 15, 2004 as GA.
2.0.50 : released June 30, 2004 as GA.
2.0.49 : released March 19, 2004 as GA.
2.0.48 : released October 29, 2003 as GA.
2.0.47 : released July 09, 2003 as GA.
2.0.46 : released May 28, 2003 as GA.
2.0.45 : released April 1, 2003 as GA.
2.0.44 : released January 20, 2003 as GA.
2.0.43 : released October 3, 2002 as GA.
2.0.42 : released September 24, 2002 as GA.
2.0.41 : rolled September 16, 2002. not released.
2.0.40 : released August 9, 2002 as GA.
2.0.39 : released June 17, 2002 as GA.
2.0.38 : rolled June 16, 2002. not released.
2.0.37 : rolled June 11, 2002. not released.
2.0.36 : released May 6, 2002 as GA.
2.0.35 : released April 5, 2002 as GA.
2.0.34 : tagged March 26, 2002.
2.0.33 : tagged March 6, 2002. not released.
2.0.32 : released Feburary 16, 2002 as beta.
2.0.31 : rolled Feburary 1, 2002. not released.
2.0.30 : tagged January 8, 2002. not rolled.
2.0.29 : tagged November 27, 2001. not rolled.
2.0.28 : released November 13, 2001 as beta.
2.0.27 : rolled November 6, 2001
2.0.26 : tagged October 16, 2001. not rolled.
2.0.25 : rolled August 29, 2001
2.0.24 : rolled August 18, 2001
2.0.23 : rolled August 9, 2001
2.0.22 : rolled July 29, 2001
2.0.21 : rolled July 20, 2001
2.0.20 : rolled July 8, 2001
2.0.19 : rolled June 27, 2001
2.0.18 : rolled May 18, 2001
2.0.17 : rolled April 17, 2001
2.0.16 : rolled April 4, 2001
2.0.15 : rolled March 21, 2001
2.0.14 : rolled March 7, 2001
2.0a9 : released December 12, 2000
2.0a8 : released November 20, 2000
2.0a7 : released October 8, 2000
2.0a6 : released August 18, 2000
2.0a5 : released August 4, 2000
2.0a4 : released June 7, 2000
2.0a3 : released April 28, 2000
2.0a2 : released March 31, 2000
2.0a1 : released March 10, 2000
Please consult the following STATUS files for information on related projects:
* http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x/STATUS
* http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x/STATUS
* http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS
Contributors looking for a mission:
* Just do an egrep on TODO or XXX in the source.
* Review the bug database at: http://issues.apache.org/bugzilla/
* Review the PatchAvailable bugs in the bug database:
http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable
After testing, you can append a comment saying Reviewed and tested.
* Open bugs in the bug database.
CURRENT RELEASE NOTES:
* Forward binary compatibility is expected of Apache 2.0.x releases, such
that no MMN major number changes will occur. Such changes can only be
made in the trunk.
* All commits to branches/2.0.x must be reflected in SVN trunk,
as well, if they apply. Logical progression is commit to trunk,
get feedback and votes in STATUS, and then merge into branches/2.0.x.
RELEASE SHOWSTOPPERS:
PATCHES TO BACKPORT FROM TRUNK:
[ please place SVN revisions from trunk here, so it is easy to
identify exactly what the proposed changes are! ]
[ please append new backports at the end of this list not the top. ]
*) ap_proxy_canonenc() is over-eager in handling '%' for reverse
proxies (PR: 29554).
Index: modules/proxy/proxy_util.c
- if (isenc ch == '%') {
+ if (isenc (isenc != PROXYREQ_REVERSE) ch == '%') {
+1: jim
*) several changes to improve logging of connection-oriented errors,
including
ap_log_cerror() API (needs minor bump in addition to changes below)
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/core.c?r1=1.289r2=1.291
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/server/log.c?r1=1.150r2=1.151
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/include/http_log.h?r1=1.46r2=1.48
+1: trawick, stoddard
-0: wrowe; seems this (valid) improvement would encourage non-compatible
mods.
*) mod_headers: Support {...}s tag for SSL variable lookup.
http://www.apache.org/~jorton/mod_headers-2.0-ssl.diff
+1: jorton, trawick
nd: two comments:
(1) is the use of APR_ASCII_* ebcdic-safe? I.e. shouldn't we use the
native chars
[STATUS] (httpd-2.1) Wed May 11 23:46:35 2005
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2005-05-02 16:21:40 -0400 (Mon, 02 May 2005) $] The current version of this file can be found at: http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Release history: [NOTE that only Alpha/Beta releases occur in 2.1 development] 2.1.5 : in development 2.1.4 : not released. 2.1.3 : Released on 2/22/2005 as alpha. 2.1.2 : Released on 12/08/2004 as alpha. 2.1.1 : Released on 11/19/2004 as alpha. 2.1.0 : not released. Please consult the following STATUS files for information on related projects: * http://svn.apache.org/repos/asf/apr/apr/trunk/STATUS * http://svn.apache.org/repos/asf/apr/apr-util/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS Contributors looking for a mission: * Just do an egrep on TODO or XXX in the source. * Review the bug database at: http://issues.apache.org/bugzilla/ * Review the PatchAvailable bugs in the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: RELEASE SHOWSTOPPERS: * Handling of non-trailing / config by non-default handler is broken http://marc.theaimsgroup.com/?l=apache-httpd-devm=105451701628081w=2 jerenkrantz asks: Why should this block a release? * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-devm=105366252619530w=2 jerenkrantz asks: Why should this block a release? stas replies: because it requires a rewrite of the filters stack implementation (you have suggested that) and once 2.2 is released you can't do that anymore. CURRENT VOTES: * httpd-std.conf and friends a) httpd-std.conf should be tailored by install (from src or binbuild) even if user has existing httpd.conf +1: trawick, slive, gregames, ianh, Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - prefer httpd.default.conf to avoid ambiguity with cvs b) tailored httpd-std.conf should be copied by install to sysconfdir/examples -0: striker c) tailored httpd-std.conf should be installed to sysconfdir/examples or manualdir/exampleconf/ +1: slive, trawick, Ken, nd (prefer the latter), erikabele d) Installing a set of default config files when upgrading a server doesn't make ANY sense at all. +1: ianh - medium/big sites don't use 'standard config' anyway, as it usually needs major customizations -1: Ken, wrowe, jwoolley, jim, nd, erikabele wrowe - diff is wonderful when comparing old/new default configs, even for customized sites that ianh mentions jim - ... assuming that the default configs have been updated with the required inline docs to explain the changes * If the parent process dies, should the remaining child processes gracefully self-terminate. Or maybe we should make it a runtime option, or have a concept of 2 parent processes (one being a hot spare). See: Message-ID: [EMAIL PROTECTED] Self-destruct: Ken, Martin, Lars Not self-destruct: BrianP, Ian, Cliff, BillS Make it runtime configurable: Aaron, jim, Justin, wrowe, rederpj, nd /* The below was a concept on *how* to handle the problem */ Have 2 parents: +1: jim -1: Justin, wrowe, rederpj, nd +0: Lars, Martin (while standing by, could it do something useful?) * Make the worker MPM the default MPM for threaded Unix boxes. +1: Justin, Ian, Cliff, BillS, striker, wrowe, nd +0: BrianP, Aaron (mutex contention is looking better with the latest code, let's continue tuning and testing), rederpj, jim -0: Lars pquerna: Do we want to change this for 2.2? RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Patches submitted to the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable * The Event MPM does not work on Solaris 10. PR 34040. * Filter stacks and subrequests, redirects and fast redirects. There's at least one PR that suffers from the current unclean behaviour (which lets the server send garbage): PR 17629 nd says: Every subrequest should get its own filter stack with the subreq_core filter as bottom-most. That filter does two things: - swallow EOS buckets
[STATUS] (httpd-test: flood) Wed May 11 23:46:48 2005
flood STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Release: 1.0: Released July 23, 2002 milestone-03: Tagged January 16, 2002 ASF-transfer: Released July 17, 2001 milestone-02: Tagged August 13, 2001 milestone-01: Tagged July 11, 2001 (tag lost during transfer) RELEASE SHOWSTOPPERS: * Everything needs to work perfectly Other bugs that need fixing: * I get a SIGBUS on Darwin with our examples/round-robin-ssl.xml config, on the second URL. I'm using OpenSSL 0.9.6c 21 dec 2001. * iPlanet sends Content-length - there is a hack in there now to recognize it. However, all HTTP headers need to be normalized before checking their values. This isn't easy to do. Grr. * OpenSSL 0.9.6 Segfaults under high load. Upgrade to OpenSSL 0.9.6b. Aaron says: I just found a big bug that might have been causing this all along (we weren't closing ssl sockets). How can I reproduce the problem you were seeing to verify if this was the fix? * SEGVs when /tmp/.rnd doesn't exist are bad. Make it configurable and at least bomb with a good error message. (See Doug's patch.) Status: This is fixed, no? * If APR has disabled threads, flood should as well. We might want to have an enable/disable parameter that does this also, providing an error if threads are desired but not available. * flood needs to clear pools more often. With a long running test it can chew up memory very quickly. We should just bite the bullet and create/destroy/clear pools for each level of our model: farm, farmer, profile, url/request-cycle, etc. * APR needs to have a unified interface for ephemeral port exhaustion, but aparently Solaris and Linux return different errors at the moment. Fix this in APR then take advantage of it in flood. * The examples/analyze-relative scripts fail when there are less than 5 unique URLs. Other features that need writing: * More analysis and graphing scripts are needed * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. Jacek is working on a Mozilla application, codename Flood URL bag (much like Live HTTP Headers) and small HTTP proxy. * Get chunked encoding support working. Status: Justin volunteers. He got sidetracked by the httpd implementation of input filtering and never finished this. This is a stopgap until apr-serf is completed. * Maybe we should make randfile and capath runtime directives that come out of the XML, instead of autoconf parameters. * We are using apr_os_thread_current() and getpid() in some places when what we really want is a GUID. The GUID will be used to correlate raw output data with each farmer. We may wish to print a unique ID for each of farm, farmer, profile, and url to help in postprocessing. * We are using strtol() in some places and strtoll() in others. Pick one (Aaron says strtol(), but he's not sure). * Validation of responses (known C-L, specific strings in response) Status: Justin volunteers * HTTP error codes (ie. teach it about 302s) Justin says: Yeah, this won't be with round_robin as implemented. Need a linked list-based profile where we can insert new URLs into the sequence. * Farmer (Single-thread, multiple profiles) Status: Aaron says: If you have threads, then any Farmer can be run as part of any Farm. If you don't have threads, you can currently only run one Farmer named Joe right now (this will be changed so that if you don't have threads, flood will attempt to run all Farmers in serial under one process). * Collective (Single-host, multiple farms) This is a number of Farms that have been fork()ed into child processes. * Megaconglomerate (Multiple hosts each running a collective) This is a number of Collectives running on a number of hosts, invoked via RSH/SSH or maybe even some proprietary mechanism. * Other types of urllists a) Random / Random-weighted b) Sequenced (useful with cookie propogation) c) Round-robin d) Chaining of the above strategies Status: Round-robin is complete. * Other types of reports Status: Aaron says: simple reports are functional. Justin added a new type that simply prints the approx. timestamp when the test was run, and the result as OK/FAIL; it is called easy reports (see flood_easy_reports.h).
[STATUS] (httpd-test: perl-framework) Wed May 11 23:46:56 2005
httpd-test/perl-framework STATUS: -*-text-*- Last modified at [$Date: 2004-11-24 19:36:41 -0500 (Wed, 24 Nov 2004) $] Stuff to do: * finish the t/TEST exit code issue (ORed with 0x2C if framework failed) * change existing tests that frob the DocumentRoot (e.g., t/modules/access.t) to *not* do that; instead, have Makefile.PL prepare appropriate subdirectory configs for them. Why? So t/TEST can be used to test a remote server. * problems with -d perl mode, doesn't work as documented Message-ID: [EMAIL PROTECTED] Date: Sat, 20 Oct 2001 12:58:33 +0800 Subject: Re: perldb Tests to be written: * t/apache - simulations of network failures (incomplete POST bodies, chunked and unchunked; missing POST bodies; slooow client connexions, such as taking 1 minute to send 1KiB; ...) * t/modules/autoindex - something seems possibly broken with inheritance on 2.0 * t/ssl - SSLPassPhraseDialog exec: - SSLRandomSeed exec:
