svn commit: rev 53997 - incubator/httpd/cli/trunk/mod_aspdotnet
Author: wrowe Date: Thu Oct 7 09:43:07 2004 New Revision: 53997 Modified: incubator/httpd/cli/trunk/mod_aspdotnet/License.rtf Log: Well that was overkill, lots of extra bits left over from HTTP that we don't need here. Modified: incubator/httpd/cli/trunk/mod_aspdotnet/License.rtf == Binary files /tmp/tmpuaj4nK and /tmp/tmp_y9EWw differ
svn commit: rev 53994 - incubator/httpd/cli/trunk/mod_aspdotnet/installer
Author: wrowe Date: Thu Oct 7 09:36:01 2004 New Revision: 53994 Modified: incubator/httpd/cli/trunk/mod_aspdotnet/installer/Directory.idt Log: Fix two unresolved paths in the msi Directory table. Modified: incubator/httpd/cli/trunk/mod_aspdotnet/installer/Directory.idt == --- incubator/httpd/cli/trunk/mod_aspdotnet/installer/Directory.idt (original) +++ incubator/httpd/cli/trunk/mod_aspdotnet/installer/Directory.idt Thu Oct 7 09:36:01 2004 @@ -2,8 +2,8 @@ s72S72 l255S255I4 Directory Directory APACHE_ROOTINSTALLDIR . 0 -APACHE_GROUP ProgramFilesFolder .:APACHE~1|Apache Group 0 -APACHE_MODULES APACHE modules 0 +APACHE_GROUP ProgramFilesFolder APACHE~1|Apache Group 0 +APACHE_MODULES APACHE_ROOT modules 0 DesktopFolder TARGETDIR .:Desktop 0 DOCS INSTALLDIR docs0 FontsFolderTARGETDIR .:Fonts 0 @@ -15,6 +15,7 @@ PDFDOCSPDF 0 PersonalFolder TARGETDIR .:Personal 0 PrimaryVolumePath TARGETDIR .:Primar~1|PrimaryVolumePath 0 +ProgramFilesFolder TARGETDIR .:Progra~1|Program Files 0 ProgramFiles64Folder TARGETDIR .:Prog64~1|Program Files 64 0 ProgramMenuFolder TARGETDIR .:Programs 3 SendToFolder TARGETDIR .:SendTo3
Re: performance
At 03:37 PM 10/7/2004, hammett wrote: From: William A. Rowe, Jr. [EMAIL PROTECTED] There is one interesting consideration... do we want two separate keys, one dev key (the one in there now) used by anyone who builds this package themselves (unless, if they would like they can create their own) ... and the other used for official binary release (and held by the release manager alone)? This is a pain, but seems like a one viable strategy. A better strategy would be to have the key on the SVN but not publically available. When we deal in pgp key files, we countersign one another's keys but maintain strict possession of our own. I'm thinking that if we have, instead of a KEYS file, another master file containing the keys of all release managers. Anyone can use the public key for their own -dev builds, or stuff in their own, but either way the mod_aspdotnet must match to the Apache.Web sk file. The big pain would be if a user tried to build -only- mod_aspdotnet or Apache.Web themselves. At that point they would be out-of-sync. Of course, with a bit of documentation in README this problem could be dispensed with right away.
mod_aspdotnet SVN rev 54000 build dev snapshots available
Binary test build is available in; http://www.apache.org/~wrowe/mod_aspdotnet-20041007-dev.msi and source tarball available in; http://www.apache.org/~wrowe/mod_aspdotnet-20041007-dev-source.zip These are from trunk today, rev 54000 If playing with this module, review README and aspnet.conf in; http://svn.apache.org/repos/asf/incubator/httpd/cli/trunk/mod_aspdotnet/
[STATUS] (flood) Wed Oct 6 23:45:31 EDT 2004
flood STATUS: -*-text-*- Last modified at [$Date: 2003/07/01 20:55:12 $] 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). Furthermore,
RE: Bye bye welcome page
If I was a newbie, and I saw a page that says `it worked`, my immediate reaction would be `what worked?` and I would start asking the exact questions we`re trying to stop people from asking. We can always go with simply displaying a meaningless word like 'Waboozle'. And so the madness begins again.. Let's just trust Josh to come up with a really short message like Your web server installation has succeeded, now you need to write some content. or It worked!. And yes, it's only in english. At the end of the day, if somebody can't work out what that means who's going to want to read their pages anyway? :-) John
mod_disk_cache directives naming convention
All the directives for mod_mem_cache are preceded with an "M". The ones for mod_cache are starting with a "c" Should all the disk_cache directives be preceded with a "D" for consistency and clarity? I know it is going to break every user configuration, but before the modules move out of experimental is probably the less painful time to do that change. Thanks, JJ
Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
Mladen Turk wrote: [snip] Both apr and libhttpd has more then 100 of those when /Wp64 is used, so IMO we would just hide the problems under carpet if just casting every 64-32 warning found. Agreed, hiding underlying problems is not acceptable. I am trying to address the many warnings that a Win64 build spits out in the correct way, not just for the sake of suppressing warnings. For example inside http_protocol.c you have: (i.e. in the current http_protocol.c code) 'int len = strlen(method)', that is wrong by all means, but I wouldn't write that as 'int len = (int)strlen(method)' just to make the compiler happy, but rather use 'size_t len = strlen(method)'. Agreed. In the patch just posted you'll see mod_win32.c takes the approach you suggest, as does a patch I have been working on that addresses http_protocol.c and other warnings. I will be posting this shortly. Well, that one is probably OK. I was talking about the concept of not casting just for the sake of making compiler happy. Agree. Thanks, Allan
Re: mod_disk_cache directives naming convention
--On Thursday, October 7, 2004 9:08 AM -0600 Jean-Jacques Clar [EMAIL PROTECTED] wrote: All the directives for mod_mem_cache are preceded with an M. The ones for mod_cache are starting with a c Should all the disk_cache directives be preceded with a D for consistency and clarity? I know it is going to break every user configuration, but before the modules move out of experimental is probably the less painful time to do that change. I *really* don't like the M prefix at all. I'd much prefer us to just spell the thing out: CacheMem* and CacheDisk* instead of MCache and/or DCache. I think a single letter prefix is really ambiguous. M what? That said, there are a number of directives currently in mod_disk_cache that aren't implemented (and I don't see being implemented anytime soon): such as CacheSize, CacheGcInterval, CacheExpiryCheck, CacheTimeMargin, CacheGcDaily, CacheGcUnused, CacheGcClean, CacheGcMemUsage. If we go through the process of renaming the directives (and I'm +1 to making it consistent per my first paragraph), I'd like to see us toss all of the directives we don't implement. BTW, are you volunteering to take the lead on this? ;-) -- justin
Bug: Apache hangs if script invokes fork/waitpid
The Problem:
---
I notice Apache 2(worker mpm) is not able to correctly handle
a fork/waitpid invoked by a script used with mod_perl.
Here is a simple cgi perl script to reproduce the problem (run under
mod_perl).
#!/opt/perl/bin/perl
print Content-Type: text/plain; charset=euc-jp\n\n;
$pid=fork();
if( $pid == 0 ) {
sleep(15);
}
else {
waitpid($pid,0);
}
Run this cgi perl script under mod_perl (with ExecCGI option).
The call to fork in the perl script actually creates a child process
that is
identical to the Apache process currently handling the request. This
situation,
I believe, is somewhat different if the cgi script was run under
mod_cgi.
The forked child is not exactly identical to its parent
since the forked process only has the worker thread and no other threads
(i.e listner or the main thread waiting on POD or the other workers).
Now the funny thing is that once the forked process completes executing
the
remainder of the Perl script it returns back to the worker thread who
happily
goes back to ap_queue_pop waiting for someone to feed it more requests
to
handle...instead of terminating. And there is no one to feed it
anything.
Now the parent process (or perl script that invoked fork())
is performing a waitpid() for this child and thus blocked forever.
This effectively has made one worker thread useless. Invoking a second
request will
cause another worker thread to go down the drain and you can continue to
do this
till all worker process are put into a never ending wait. If Apache has
been constrained
by MaxClients to some value N, then N requests will efectively cause
Apache to
stop responding to further requests.
Essentially the forked Apache process does not know that it is not a
real Apache
worker process.
Fixing it:
-
First Solution :
The natural fix for this is to somehow make the forked worker aware that
it is not a real
worker and thus it should not go back to waiting for more requests once
its done. So
essentally in the worker_thread function we check if ap_my_pid ==
getpid() before continuing
into the next iteration of the while loop around ap_queue_pop().
ap_my_pid actually has the
pid of the (real) worker that forked the child worker.
static void * APR_THREAD_FUNC worker_thread(apr_thread_t *thd, void *
dummy)
{
// ... snip ...
while (!workers_may_exit)
{
// ... snip ...
worker_pop:
if (workers_may_exit) {
break;
}
/*break from loop if this worker was forked by another
worker*/
if ( ap_my_pid != getpid() ) {
break; // or apr_thread_exit(..) or exit(NULL);
}
rv = ap_queue_pop(worker_queue, csd, ptrans);
// ... snip ...
} // end while
// ... snip ..
}
However there is a problem with this approach. The connection is closed
(by the forked worker)
even before the next iteration of while loop. This causes a problem for
the parent who is
blocked on waitpid(). Consequently when the child returns control back
to the parent the parent
can no longer talk to the client. So the core_output_filter of the
parent prints out an error
message saying broken pipe in the error log.
It seems that the connection is closed by the worker in the apr_sendv()
function call itself !
So once the child has completed sending all its output, the connection
is closed immediately.
I thought it might be a better idea to invoke apr_thread_exit() instead
of break to prohibit
the forked worker from cleaning up any of the data structures that
actually belong to its
parent. But apr_thread_exit calls this..
...
apr_pool_destroy(thd-pool); // this cleans up stuff that belongs to
the parent!!
pthread_exit(NULL);
...
Second solution:
Is to invoke exit(0) (if we are in the forked worker) just after
ap_run_handler is invoked
by ap_invoke_handler
AP_CORE_DECLARE(int) ap_invoke_handler(request_rec *r)
|
{
// ...snip
result = ap_run_handler(r);
if ( I am a forked worker ) {
exit(0); // terminate at the earliest possible stage after
request was processed
}
// ...snip
}
Unfortunately this leaves us with a different problem (although a
smaller problem)
What happens here is that the forked child did all its request
processing, but never is not
given a chance to send any data out back to client(if it has any). But
then the catch-22 is
that if we allow it to send all its data out..then it will close the
connection too.
In summary:
Second solution seems preferrable among the two I have suggested.
If I had to chose between disallowing the parent or child from sending
data back, I would
disallow the child. Either way, parent is allowed to write stuff back
until the child closes
the connection. From my point of view, as forking is more useful for
performing time consuming
background tasks, rather than
Re: mod_disk_cache directives naming convention
Justin Erenkrantz wrote: That said, there are a number of directives currently in mod_disk_cache that aren't implemented (and I don't see being implemented anytime soon): such as CacheSize, CacheGcInterval, CacheExpiryCheck, CacheTimeMargin, CacheGcDaily, CacheGcUnused, CacheGcClean, CacheGcMemUsage. If we go through the process of renaming the directives (and I'm +1 to making it consistent per my first paragraph), I'd like to see us toss all of the directives we don't implement. Not nice, IMHO. One major problem that prevents the use of apache 2.x for me is the fact that the cache size cannot be constrained. A cache that can grow without constraint can't be used on production systems. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
Re: mod_disk_cache directives naming convention
--On Thursday, October 7, 2004 7:21 PM +0200 Andreas Steinmetz [EMAIL PROTECTED] wrote: Not nice, IMHO. One major problem that prevents the use of apache 2.x for me is the fact that the cache size cannot be constrained. A cache that can grow without constraint can't be used on production systems. Feel free to submit a patch that efficiently allows the constraint of the cache size. I just don't see a way to do that as mod_disk_cache does not have any indexing. IMHO, instead of making a false promise, we should remove it. If we were to add such a feature later, we can add such directives accordingly. -- justin
Re: mod_disk_cache directives naming convention
Justin Erenkrantz wrote: --On Thursday, October 7, 2004 7:21 PM +0200 Andreas Steinmetz [EMAIL PROTECTED] wrote: Not nice, IMHO. One major problem that prevents the use of apache 2.x for me is the fact that the cache size cannot be constrained. A cache that can grow without constraint can't be used on production systems. Feel free to submit a patch that efficiently allows the constraint of the cache size. I just don't see a way to do that as mod_disk_cache does not have any indexing. I'll have a look, though it will take a while. Whatever the result I'll post it. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
Re: mod_disk_cache directives naming convention
[EMAIL PROTECTED] 10/07/04 11:14 AM --On Thursday, October 7, 2004 9:08 AM -0600 Jean-Jacques Clar [EMAIL PROTECTED] wrote:I *really* don't like the M prefix at all. I'd much prefer us to just spell the thing out: CacheMem* and CacheDisk* instead of MCache and/or DCache. I think a single letter prefix is really ambiguous. M what? I am not going to fight you on the prefix. I just want it to be different for each module, that is what I will like to get done here. I won't probably agree if we use 'Waboozle', and I suggest that the description should with the name of the module like MemCache* and DiskCache* to make it easier for related directives to be grouped together (sorted). If we go through the process of renaming the directives (and I'm +1 to making it consistent per my first paragraph), I'd like to see us toss all of the directives we don't implement.My only worry there is that they will disappearforever instead of always annoying us every time we open the c file or look at the doc page. BTW, are you volunteering to take the lead on this? ;-) -- justinYes with pleasure, this is why I started the debate. JJ
Re: mod_disk_cache directives naming convention
--On Thursday, October 7, 2004 12:13 PM -0600 Jean-Jacques Clar [EMAIL PROTECTED] wrote: I won't probably agree if we use 'Waboozle', and I suggest that the description should with the name of the module like MemCache* and DiskCache* to make it easier for related directives to be grouped together (sorted). I'd really prefer for all caching directives to be under Cache* so that the alphabetical ordering of the directives that we generate in our docs group them together. Using MemCache* and DiskCache* instead of CacheMem* and CacheDisk* sort of blow that away. (However, I won't fight this too hard, but just want to make my preference clear.) If we go through the process of renaming the directives (and I'm +1 to making it consistent per my first paragraph), I'd like to see us toss all of the directives we don't implement. My only worry there is that they will disappear forever instead of always annoying us every time we open the c file or look at the doc page. If we truly mean for it to be out of experimental, then it shouldn't have any no-op directives. That's exceedingly bad form, IMHO. BTW, are you volunteering to take the lead on this? ;-) -- justin Yes with pleasure, this is why I started the debate. Yay! -- justin
Re: Bug: Apache hangs if script invokes fork/waitpid
On Wed, 6 Oct 2004 11:01:23 -0700, Naik, Roshan [EMAIL PROTECTED] wrote: The Problem: --- I notice Apache 2(worker mpm) is not able to correctly handle a fork/waitpid invoked by a script used with mod_perl. From Ulrich Drepper: No threaded programs must use anything but _exit or exec after fork. Perhaps a tiny bit harsh? What if you fork a copy of a mutex used by some third-party Apache module? That module would need to be using pthread_atfork() to make sure ownership is preserved properly. Apache/APR certainly doesn't do it with its mutexes. I think there needs to be a mod_fork which provides a more general purpose daemon than that used by mod_cgid, and some Apache API will know whether or not to send a request over there. This preserves the goal of having fork() called only by single-threaded processes so that all manner of pain is avoided.
Re: Bug: Apache hangs if script invokes fork/waitpid
Jeff Trawick wrote: I think there needs to be a mod_fork which provides a more general purpose daemon than that used by mod_cgid, and some Apache API will know whether or not to send a request over there. This preserves the goal of having fork() called only by single-threaded processes so that all manner of pain is avoided. Big +1 from me in concept. I am not sure how to do the implementation best. mod_cgid doesn't really 'fork' in the sense most programs do, its mostly just starting up a cgi process -- from an executable on the file system. This seems drastically different from the requirements of a generic fork(). Any thoughts on how you would want to implement this in a generic manner for any call from anywhere for any module? -Paul Querna
[PATCH] WIN64: httpd API changes
This set of changes gets rid of most of the libhttpd 64bit warnings on Windows at the cost of several httpd API changes. I defined AP_INT_TRUNC_CAST for use where there are size mismatches with APR API's (those APR API's will need to be updated in APR 2.0) Comments before I commit? Allan - Index: include/ap_mmn.h === RCS file: /home/cvs/httpd-2.0/include/ap_mmn.h,v retrieving revision 1.69 diff -U3 -r1.69 ap_mmn.h --- include/ap_mmn.h4 Jun 2004 22:40:46 - 1.69 +++ include/ap_mmn.h7 Oct 2004 20:48:55 - @@ -84,14 +84,15 @@ * changed ap_add_module, ap_add_loaded_module, * ap_setup_prelinked_modules, ap_process_resource_config * 20040425.1 (2.1.0-dev) Added ap_module_symbol_t and ap_prelinked_module_symbols + * 20041007 (2.1.0-dev) API changes to clean up 64bit compiles */ #define MODULE_MAGIC_COOKIE 0x41503230UL /* AP20 */ #ifndef MODULE_MAGIC_NUMBER_MAJOR -#define MODULE_MAGIC_NUMBER_MAJOR 20040425 +#define MODULE_MAGIC_NUMBER_MAJOR 20041007 #endif -#define MODULE_MAGIC_NUMBER_MINOR 1 /* 0...n */ +#define MODULE_MAGIC_NUMBER_MINOR 0 /* 0...n */ /** * Determine if the server's current MODULE_MAGIC_NUMBER is at least a Index: include/http_protocol.h === RCS file: /home/cvs/httpd-2.0/include/http_protocol.h,v retrieving revision 1.92 diff -U3 -r1.92 http_protocol.h --- include/http_protocol.h 18 Jul 2004 20:06:38 - 1.92 +++ include/http_protocol.h 7 Oct 2004 20:48:55 - @@ -340,7 +340,7 @@ * @return The number of bytes sent * @deffunc int ap_rputs(const char *str, request_rec *r) */ -AP_DECLARE(int) ap_rputs(const char *str, request_rec *r); +AP_DECLARE(apr_size_t) ap_rputs(const char *str, request_rec *r); /** * Write a buffer for the current request @@ -359,7 +359,7 @@ * @return The number of bytes sent * @deffunc int ap_rvputs(request_rec *r, ...) */ -AP_DECLARE_NONSTD(int) ap_rvputs(request_rec *r,...); +AP_DECLARE_NONSTD(apr_size_t) ap_rvputs(request_rec *r,...); /** * Output data to the client in a printf format @@ -369,7 +369,7 @@ * @return The number of bytes sent * @deffunc int ap_vrprintf(request_rec *r, const char *fmt, va_list vlist) */ -AP_DECLARE(int) ap_vrprintf(request_rec *r, const char *fmt, va_list vlist); +AP_DECLARE(apr_size_t) ap_vrprintf(request_rec *r, const char *fmt, va_list vlist); /** * Output data to the client in a printf format @@ -379,7 +379,7 @@ * @return The number of bytes sent * @deffunc int ap_rprintf(request_rec *r, const char *fmt, ...) */ -AP_DECLARE_NONSTD(int) ap_rprintf(request_rec *r, const char *fmt,...) +AP_DECLARE_NONSTD(apr_size_t) ap_rprintf(request_rec *r, const char *fmt,...) __attribute__((format(printf,2,3))); /** * Flush all of the data for the current request to the client @@ -445,7 +445,7 @@ * if EOF, or -1 if there was an error * @deffunc long ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz) */ -AP_DECLARE(long) ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz); +AP_DECLARE(apr_size_t) ap_get_client_block(request_rec *r, char *buffer, apr_size_t bufsiz); /** * In HTTP/1.1, any method can have a body. However, most GET handlers Index: include/httpd.h === RCS file: /home/cvs/httpd-2.0/include/httpd.h,v retrieving revision 1.212 diff -U3 -r1.212 httpd.h --- include/httpd.h 12 Aug 2004 05:22:59 - 1.212 +++ include/httpd.h 7 Oct 2004 20:48:55 - @@ -1091,7 +1091,7 @@ /** Pathname for ServerPath */ const char *path; /** Length of path */ -int pathlen; +apr_size_t pathlen; /** Normal names for ServerAlias servers */ apr_array_header_t *names; @@ -1244,7 +1244,7 @@ * address of field is shifted to the next non-comma, non-whitespace * character. len is the length of the item excluding any beginning whitespace. */ -AP_DECLARE(const char *) ap_size_list_item(const char **field, int *len); +AP_DECLARE(const char *) ap_size_list_item(const char **field, apr_size_t *len); /** * Retrieve an HTTP header field list item, as separated by a comma, @@ -1587,7 +1587,7 @@ * @param c The character to search for * @return The index of the first occurrence of c in str */ -AP_DECLARE(int) ap_ind(const char *str, char c); /* Sigh... */ +AP_DECLARE(apr_size_t) ap_ind(const char *str, char c);/* Sigh... */ /** * Search a string from right to left for the first occurrence of a @@ -1596,7 +1596,7 @@ * @param c The character to search for * @return The index of the first occurrence of c in str */ -AP_DECLARE(int) ap_rind(const char *str, char c); +AP_DECLARE(apr_size_t) ap_rind(const char *str, char c); /** * Given a string, replace any bare
RE: Bye bye welcome page
On Thu, 2004-10-07 at 12:08, John Rowe wrote: If I was a newbie, and I saw a page that says `it worked`, my immediate reaction would be `what worked?` and I would start asking the exact questions we`re trying to stop people from asking. We can always go with simply displaying a meaningless word like 'Waboozle'. And so the madness begins again.. [...] I do hope everyone realizes I was kidding. The only thing we have to do is agree on a concise and clear message. I don't think it is we are likely to reach concensus on proze like the welcome page. Other than lazy concensus that is. FWIW, I'm fine with Joshua's suggestion. Sander
Re: mod_disk_cache directives naming convention
On Thu, Oct 07, 2004 at 12:12:57PM -0700, Justin Erenkrantz wrote: --On Thursday, October 7, 2004 12:13 PM -0600 Jean-Jacques Clar [EMAIL PROTECTED] wrote: I won't probably agree if we use 'Waboozle', and I suggest that the description should with the name of the module like MemCache* and DiskCache* to make it easier for related directives to be grouped together (sorted). I'd really prefer for all caching directives to be under Cache* so that the alphabetical ordering of the directives that we generate in our docs group them together. Using MemCache* and DiskCache* instead of CacheMem* and CacheDisk* sort of blow that away. +1 directives should be grouped into module namespace prefixes whenever possible Not only will things sort together in web pages, but this is more intuitive for many non-English speakers since many languages put the adjectives after the noun, i.e. the subdescription after the description. Cheers, Glenn
Re: PATCH to use apr-iconv
--On Tuesday, October 5, 2004 10:56 AM +0200 jean-frederic clere [EMAIL PROTECTED] wrote: I have now moved all the logic to apr-util. Find enclosed the new patch. To get it working checkout apr-iconv in srclib and add --with-iconv=`pwd`/srclib/apr-iconv. More comments? Besides the fact that this conversation belongs on [EMAIL PROTECTED], I think the ../apr-iconv directory should only be configured when it is present *and* a suitable system iconv() isn't found. This would match the behavior of our bundled expat sources. -- justin
Re: segfault in worker mpm
Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
Re: segfault in worker mpm
Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Stas Bekman wrote: Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. For some reason, your output doesn't match mine. for me the difference between 22nd and 23 starts from 3428 [1] and goes into the next day, which is not included in your output: [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch but I think I'm getting there -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: segfault in worker mpm
Stas Bekman wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apache.org/~gozer/mp2/2004-09-22+23/
That's a handy output. I'll try applying each separately to see which
one was the trigger.
For some reason, your output doesn't match mine. for me the difference
between 22nd and 23 starts from 3428 [1] and goes into the next day,
which is not included in your output:
[1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
but I think I'm getting there
It seems that this patch applied as reversed to the checkout from 23 Sept
resolves the segfault in t/filter/both_str_req_add.t. As you can see all
the changes are in creating new Vhosts entries.
However this doesn't resolve the current cvs problem, as I think there
were more entries added after Sept 23th, that cause the latest one.
diff -ru --exclude=CVS t/hooks/TestHooks/init.pm t/hooks/TestHooks/init.pm
--- t/hooks/TestHooks/init.pm 2003-08-11 16:34:22.0 -0400
+++ t/hooks/TestHooks/init.pm 2004-09-22 21:44:10.0 -0400
@@ -54,11 +54,15 @@
1;
__DATA__
-PerlInitHandler TestHooks::init::second
-Base
+NoAutoConfig
+ VirtualHost TestHooks::init
PerlModule TestHooks::init
PerlInitHandler TestHooks::init::first
-/Base
-PerlResponseHandler TestHooks::init
-PerlResponseHandler TestHooks::init::response
-SetHandler modperl
+Location /TestHooks__init
+PerlInitHandler TestHooks::init::second
+PerlResponseHandler TestHooks::init
+PerlResponseHandler TestHooks::init::response
+SetHandler modperl
+/Location
+ /VirtualHost
+/NoAutoConfig
diff -ru --exclude=CVS t/response/TestUser/rewrite.pm
t/response/TestUser/rewrite.pm
--- t/response/TestUser/rewrite.pm 2004-07-09 17:52:49.0 -0400
+++ t/response/TestUser/rewrite.pm 2004-09-22 21:44:11.0 -0400
@@ -62,6 +62,7 @@
1;
__END__
NoAutoConfig
+ VirtualHost TestUser::rewrite
PerlModule TestUser::rewrite
PerlTransHandlerTestUser::rewrite::trans
PerlMapToStorageHandler TestUser::rewrite::map2storage
@@ -69,5 +70,6 @@
SetHandler modperl
PerlResponseHandler TestUser::rewrite::response
/Location
+ /VirtualHost
/NoAutoConfig
diff -ru --exclude=CVS t/modules/proxy.t t/modules/proxy.t
--- t/modules/proxy.t 2004-08-03 12:16:22.0 -0400
+++ t/modules/proxy.t 2004-09-22 21:44:11.0 -0400
@@ -3,14 +3,19 @@
use Apache::Test;
use Apache::TestUtil;
-
use Apache::TestRequest;
-my $location = /TestModules__proxy;
+my $module = 'TestModules::proxy';
+
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug(connecting to $hostport);
plan tests = 1, (need_module('proxy')
need_access);
my $expected = ok;
-my $received = GET_BODY_ASSERT $location;
+my $received = GET_BODY_ASSERT http://$hostport/$path;;;
ok t_cmp($received, $expected, internally proxified request);
diff -ru --exclude=CVS t/response/TestModules/proxy.pm
t/response/TestModules/proxy.pm
--- t/response/TestModules/proxy.pm 2004-07-09 04:01:21.0 -0400
+++ t/response/TestModules/proxy.pm 2004-09-22 21:44:11.0 -0400
@@ -43,6 +43,7 @@
1;
__END__
NoAutoConfig
+ VirtualHost TestModules::proxy
IfModule mod_proxy.c
Proxy http://@servername@:@port@/*
IfModule @ACCESS_MODULE@
@@ -59,5 +60,6 @@
PerlResponseHandler TestModules::proxy::response
/Location
/IfModule
+ /VirtualHost
/NoAutoConfig
diff -ru --exclude=CVS t/hooks/TestHooks/trans.pm t/hooks/TestHooks/trans.pm
--- t/hooks/TestHooks/trans.pm 2003-04-18 02:18:58.0 -0400
+++ t/hooks/TestHooks/trans.pm 2004-09-22 21:44:11.0 -0400
@@ -37,5 +37,12 @@
1;
__DATA__
-PerlResponseHandler Apache::TestHandler::ok1
-SetHandler modperl
+NoAutoConfig
+ VirtualHost TestHooks::trans
+PerlTransHandler TestHooks::trans
+Location /TestHooks__trans
+PerlResponseHandler Apache::TestHandler::ok1
+SetHandler modperl
+/Location
+ /VirtualHost
+/NoAutoConfig
diff -ru --exclude=CVS t/hooks/trans.t t/hooks/trans.t
--- t/hooks/trans.t 2003-03-31 23:39:30.0 -0500
+++ t/hooks/trans.t 2004-09-22 21:44:10.0 -0400
@@ -8,15 +8,20 @@
use Apache2 ();
use Apache::Const ':common';
+my $module = 'TestHooks::trans';
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug(connecting to $hostport);
+
plan tests = 3;
t_client_log_error_is_expected();
-ok GET_RC('/nope') == NOT_FOUND;
-
-my $module =
