[STATUS] (httpd-test: flood) Wed Aug 24 23:46:53 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_repo
[STATUS] (httpd-test: perl-framework) Wed Aug 24 23:47:00 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:
[STATUS] (httpd-2.0) Wed Aug 24 23:45:41 2005
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2005-08-24 08:50:00 -0400 (Wed, 24 Aug 2005) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/docs/STATUS 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 Consult the trunk/ for all new development and documentation efforts: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/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 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=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2.0&keywords=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: * Copy the backport branch of all of the mod_proxy_http.c's request body handling security, protocol and bug fixes; by svn copy'ing the file httpd/httpd/branches/proxy-reqbody-2.0.x/modules/proxy/proxy_http.c back to httpd/branches/2.0.x/... preserving the detail of all of the individually backported changes. +1: wrowe, jim -1: For a complete history of individual unit changes, see r230703 - r230744 in http://svn.apache.org/viewcvs.cgi/httpd/httpd/branches/proxy-reqbody-2.0.x/ [...] modules/proxy/proxy_http.c?&view=log Cite the specific patch with justification for each specific objection. Suggested; revert r219061 to thoroughly test this patch, as r219061 masks some underlying bugs (although it is a -good- patch in and of itself and provides additional protection to other content-handling modules). * TRACE must not have a request body per RFC2616; see the -trace.patch below
[STATUS] (httpd-2.1) Wed Aug 24 23:46:34 2005
APACHE 2.1 STATUS: -*-text-*- Last modified at [$Date: 2005-06-30 16:42:43 -0400 (Thu, 30 Jun 2005) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS Documentation status is maintained seperately and can be found at: * docs/STATUS in this source tree, or * http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/STATUS 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 Patches considered for backport are noted in their branches' STATUS: * http://svn.apache.org/repos/asf/httpd/httpd/branches/1.3.x/STATUS * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x/STATUS Release history: [NOTE that only Alpha/Beta releases occur in 2.1 development] 2.1.7 : in development 2.1.6 : Released on 6/27/2005 as alpha. 2.1.5 : Tagged on 6/17/2005. 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. 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=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=Apache+httpd-2.0&keywords=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-dev&m=105451701628081&w=2 jerenkrantz asks: Why should this block a release? wsanchez agrees: this may be a change in behavior, but isn't clearly wrong, and even if so, it doesn't seem like a showstopper. * the edge connection filter cannot be removed http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=105366252619530&w=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 +1: wsanchez (propose sysconfdir/examples/ for diffiness) 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: * Patche
Re: What happened to the "Apache 2 cross reference"?
Nick Kew wrote: Anyway, to be really useful, you'd want not just apr_pstrdup and strdup, but also variants people might guess, like apr_strdup, ap_strdup and ap_pstrdup. That could IMO turn your contribution from a mere nice to something great! That's what I was getting at, thanks for stating it more clearly. The engine that doxygen replaced (lxr?) seemed to have this functionality, although it tended to return bad line numbers.
Re: svn commit: r239711 - /httpd/httpd/trunk/server/mpm/prefork/prefork.c
On Wed, Aug 24, 2005 at 08:21:35PM +0100, Joe Orton wrote: > > It's not fixed *just* yet, only in prefork, and the PR reporter was > > using worker. I had found the PR ;) > > Duh, I missed that, sorry. Oh I'm well ahead in the Duh stats ;) I've updated the CHANGES and PR anyway, thanks for the stupidity filter :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
serf was Re: mod_cache wishlist
--On August 24, 2005 4:21:38 PM +0100 Nick Kew <[EMAIL PROTECTED]> wrote:
So, is it time we introduced a general-purpose apr_http_client?
I'd be prepared to offer my code as a startingpoint, but I'd rather
not take the driving seat for further development and documentation.
We already went down this road with serf and it eventually got booted by
the APR PMC and the HTTP Server PMC refused to consider adding an HTTP
client library. ("We don't do clients. Go away.")
Serf, which uses APR, lives on here:
SVN:
serf-dev lists:
Serf does async, SSL, deflate (gzip *and* deflate!), pipelining, etc. It's
licensed under ALv2. For those coming from httpd-land, a lot of it will
make sense. It uses apr_pollset, so it gets KEvent/epoll for free.
FWIW, we created the serf-dev mailing list only after Greg and I got tired
of trading private emails; alas, neither one of us have had mailing list
discussions since we created it. -- justin
Re: svn commit: r239711 - /httpd/httpd/trunk/server/mpm/prefork/prefork.c
On Wed, Aug 24, 2005 at 08:18:35PM +0100, Colm MacCarthaigh wrote: > On Wed, Aug 24, 2005 at 08:08:51PM +0100, Joe Orton wrote: > > On Wed, Aug 24, 2005 at 12:02:37PM -0700, Justin Erenkrantz wrote: > > > --On August 24, 2005 4:58:14 PM + [EMAIL PROTECTED] wrote: > > > >This means that the listening sockets are freed for re-use. In the > > > >ordinary case, this makes no difference. However if for example admin > > > >changes "Listen 80" to "Listen 81" in the config, this rev makes port 80 > > > >immediately available (no waiting for the graceful children to die). > > > > > > Looks fine. However, this is probably worth a CHANGES entry. > > > > Especially since you win a free PR with this fix :) > > > > http://issues.apache.org/bugzilla/show_bug.cgi?id=28167 > > It's not fixed *just* yet, only in prefork, and the PR reporter was > using worker. I had found the PR ;) Duh, I missed that, sorry. > I'm testing worker now. Is fixing it in the non-experimental MPM's > enough to note it as fixed in the CHANGES file, or should I list the > MPM's? Having a CHANGES entry which explains the fix is limited to whatever set of MPMs sounds fine to me. joe
Re: svn commit: r239711 - /httpd/httpd/trunk/server/mpm/prefork/prefork.c
On Wed, Aug 24, 2005 at 08:08:51PM +0100, Joe Orton wrote: > On Wed, Aug 24, 2005 at 12:02:37PM -0700, Justin Erenkrantz wrote: > > --On August 24, 2005 4:58:14 PM + [EMAIL PROTECTED] wrote: > > >This means that the listening sockets are freed for re-use. In the > > >ordinary case, this makes no difference. However if for example admin > > >changes "Listen 80" to "Listen 81" in the config, this rev makes port 80 > > >immediately available (no waiting for the graceful children to die). > > > > Looks fine. However, this is probably worth a CHANGES entry. > > Especially since you win a free PR with this fix :) > > http://issues.apache.org/bugzilla/show_bug.cgi?id=28167 It's not fixed *just* yet, only in prefork, and the PR reporter was using worker. I had found the PR ;) I'm testing worker now. Is fixing it in the non-experimental MPM's enough to note it as fixed in the CHANGES file, or should I list the MPM's? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r239711 - /httpd/httpd/trunk/server/mpm/prefork/prefork.c
On Wed, Aug 24, 2005 at 12:02:37PM -0700, Justin Erenkrantz wrote: > --On August 24, 2005 4:58:14 PM + [EMAIL PROTECTED] wrote: > >This means that the listening sockets are freed for re-use. In the > >ordinary case, this makes no difference. However if for example admin > >changes "Listen 80" to "Listen 81" in the config, this rev makes port 80 > >immediately available (no waiting for the graceful children to die). > > Looks fine. However, this is probably worth a CHANGES entry. Especially since you win a free PR with this fix :) http://issues.apache.org/bugzilla/show_bug.cgi?id=28167 joe
Re: Rev: 2.1.7 Available for Testing & Voting
On Wed, Aug 24, 2005 at 10:32:12AM -0700, Sander Temme wrote: > I'm running with this patch, with -DDEBUG, on FreeBSD 4.10 (and Darwin): > > http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=111435689526926&w=2 That patch looks OK, have you sent it upstream (or checked whether it is fixed in later pcre release)? joe
Re: svn commit: r239711 - /httpd/httpd/trunk/server/mpm/prefork/prefork.c
--On August 24, 2005 4:58:14 PM + [EMAIL PROTECTED] wrote: Author: colm Date: Wed Aug 24 09:58:11 2005 New Revision: 239711 URL: http://svn.apache.org/viewcvs?rev=239711&view=rev Log: Implement "de-listening" for graceful restarts with the prefork MPM. With this change; 1.) httpd -k graceful sends SIGUSR1 to the parent pid, which in turn sends SIGUSR1 to all of the active children, 2.) Active children each close their copy of listener fd's. This means that the listening sockets are freed for re-use. In the ordinary case, this makes no difference. However if for example admin changes "Listen 80" to "Listen 81" in the config, this rev makes port 80 immediately available (no waiting for the graceful children to die). Looks fine. However, this is probably worth a CHANGES entry. Thanks! -- justin
Re: svn commit: r239710 - in /httpd/httpd/trunk: include/ap_listen.h server/listen.c
On Wed, Aug 24, 2005 at 04:51:24PM -, [EMAIL PROTECTED] wrote:
> Author: colm
> Date: Wed Aug 24 09:51:20 2005
> New Revision: 239710
>
> URL: http://svn.apache.org/viewcvs?rev=239710&view=rev
...
> +/**
> + * Loop through the global ap_listen_rec list and close each of the sockets.
> + */
> +AP_DECLARE_NONSTD(void) ap_close_listeners();
should be (void)
include/ap_listen.h:83: warning: function declaration isn't a prototype
> +
> +AP_DECLARE_NONSTD(void) ap_close_listeners() {
style nit - opening brace should be on column 1.
Otherwise looks good :)
joe
Re: Rev: 2.1.7 Available for Testing & Voting
Sander Temme wrote: I'm running with this patch, with -DDEBUG, on FreeBSD 4.10 (and Darwin): http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=111435689526926&w=2 S. Thank you! Patch works!
Re: ModPyExtension in setup.py builds another mod_python.so?
Hi Grisha, Indeed, this is built by setup.py because this makes the build under Win32 much more easier. No need to "./configure ; make ; make install" under Win32, which is a blessing since there are no default installation of sh, make, flex etc. on this platform. The "standard" way of building mod_python on Win32 is "python setup.py.in install", or "python setup.py.in bdist_wininst" if you want an executable installer. As for removing the pseudo-target if the OS is not Win32, I guess it's OK. Regards, Nicolas2005/8/24, Gregory (Grisha) Trubetskoy <[EMAIL PROTECTED]>: I was just building 3.2.0b on Linux, and noticed that an extramod_python.so (or rather mod_python_so.so) ends up being built in additionto the one built by the Makefile.It happens in setup.py resulting in a mod_python_so.so file which ends up being placed in site-packages.Why do we need ModPyExtension? Since mod_python.so is an _apache_ module,why should it be built using Python tools (rather than apxs) and why doesit need to be in the Python library path? Is this necessary for Win32? If so, should we disable it on non-Win32?Or is this something we need rethink altogether? :-)Grisha
Re: some problem about mod_ftpd
At 03:14 AM 8/23/2005, Colm MacCarthaigh wrote: >On Tue, Aug 23, 2005 at 11:45:11AM +0800, firingme wrote: >> Next, there isn't any cache mechanism in the stor&retr's handler, >> I think maybe mod_disk_cache can help here. > >In addition to mod_ftpd, there is also mod_ftp, which is in the process >of becoming an incubated httpd subproject; > >http://incubator.apache.org/projects/mod_ftp.html > >This does not currently support caching either, however that is >definitely an aim of at least one of its volunteers. Don't be too certain of that; since mod_ftp uses subrequests to serve the requested content, any filtering or caching applied may percolate to the mod_ftp protocol layer. That said, if the only content serving hook supported by mod_cache is the quick handler, it likely does not, today. Bill
Re: Rev: 2.1.7 Available for Testing & Voting
I'm running with this patch, with -DDEBUG, on FreeBSD 4.10 (and Darwin): http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=111435689526926&w=2 S. On Aug 24, 2005, at 9:51 AM, Ranier wrote: On FreeBSD 4.10 GCC 2.95.4 Httpd 2.1.7-beta with -DDEBUG -DAPR_POOL_DEBUG occurs: In file included from pcre.c:543: printint.c: In function `get_ucpname': printint.c:118: `utt' undeclared (first use in this function) printint.c:118: (Each undeclared identifier is reported only once printint.c:118: for each function it appears in.) printint.c:118: `ucp_type_table' undeclared (first use in this function) printint.c:123: warning: control reaches end of non-void function *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta/srclib/pcre. *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta/srclib/pcre. *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta/srclib. *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
ModPyExtension in setup.py builds another mod_python.so?
I was just building 3.2.0b on Linux, and noticed that an extra mod_python.so (or rather mod_python_so.so) ends up being built in addition to the one built by the Makefile. It happens in setup.py resulting in a mod_python_so.so file which ends up being placed in site-packages. Why do we need ModPyExtension? Since mod_python.so is an _apache_ module, why should it be built using Python tools (rather than apxs) and why does it need to be in the Python library path? Is this necessary for Win32? If so, should we disable it on non-Win32? Or is this something we need rethink altogether? :-) Grisha
Rev: 2.1.7 Available for Testing & Voting
On FreeBSD 4.10 GCC 2.95.4 Httpd 2.1.7-beta with -DDEBUG -DAPR_POOL_DEBUG occurs: In file included from pcre.c:543: printint.c: In function `get_ucpname': printint.c:118: `utt' undeclared (first use in this function) printint.c:118: (Each undeclared identifier is reported only once printint.c:118: for each function it appears in.) printint.c:118: `ucp_type_table' undeclared (first use in this function) printint.c:123: warning: control reaches end of non-void function *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta/srclib/pcre. *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta/srclib/pcre. *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta/srclib. *** Error code 1 Stop in /usr/src/httpd-2.1.7-beta.
Re: mod_cache wishlist
Paul Querna wrote: FWIW, I will be looking at adding support for EPoll and/or KQueue to the curl_multi_* interface sometime soonish for 'work. on the curl-dev list, I suggested just using libevent (http://www.monkey.org/~provos/libevent/), because it already encapsulates all that. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: mod_cache wishlist
Brian Akins wrote: > Nick Kew wrote: > >> Alternatively, maybe someone could post an executive summary of the >> problems and benefits of standardising on libcurl? > > > I'm pretty familiar with libcurl. Great library. Here are some issues > I have had: > > - asynchronous uses select only. FWIW, I will be looking at adding support for EPoll and/or KQueue to the curl_multi_* interface sometime soonish for 'work. -Paul
Re: mod_cache wishlist
On 8/24/05, Colm MacCarthaigh <[EMAIL PROTECTED]> wrote: > On Wed, Aug 24, 2005 at 09:18:54AM -0500, Parin Shah wrote: > > > > I have fixed that memory leak problem. also added script to include > > > > libcurl whenever this module is included. > > > > > > I hope that it doesn't mean that libcurl is going to be a permanent > > > solution, when subrequests (with minor changes) could serve the same > > > purpose. > > > > Certainly not, We would have mod-c-requester which uses sub-requests > > and not libcurl eventually. but my initial reaction after going > > through the subrequest code was that it may require significant > > refactoring. > > Will it work if you mark the subrequests as proxy requests? IE, the same > approach as mod_rewrite and the P flag. > We had considered proxy requests before. But many of us felt its not good idea to use proxy requests for re-requests. main reason was that proxy-requests creates new connection to the main server. I have not checked mod_rewrite code yet. so I would go through it and if it seems to solve our problem then it would be great. Thanks for your input. > It introduces a dependency on mod_proxy, but curl introduces a > dependency on libcurl, so that's not so bad. You are right. I believe, that shouldnt be a problem.
Re: mod_cache wishlist
Nick Kew wrote: Alternatively, maybe someone could post an executive summary of the problems and benefits of standardising on libcurl? I'm pretty familiar with libcurl. Great library. Here are some issues I have had: - asynchronous uses select only. - random crashes with openssl, normal bug stuff. - POST'ing is somewhat of a mystery. It works, but you have to tinker with it alot. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: mod_cache wishlist
Colm MacCarthaigh wrote:
On Wed, Aug 24, 2005 at 09:18:54AM -0500, Parin Shah wrote:
I have fixed that memory leak problem. also added script to include
libcurl whenever this module is included.
I hope that it doesn't mean that libcurl is going to be a permanent
solution, when subrequests (with minor changes) could serve the same
purpose.
Certainly not, We would have mod-c-requester which uses sub-requests
and not libcurl eventually. but my initial reaction after going
through the subrequest code was that it may require significant
refactoring.
Will it work if you mark the subrequests as proxy requests? IE, the same
approach as mod_rewrite and the P flag.
It introduces a dependency on mod_proxy, but curl introduces a
dependency on libcurl, so that's not so bad.
I've been through this loop a few times, and not really found a
satisfactory solution. Most recently for mod_publisher, which includes
what could perhaps become an apr_http_client module. But that's not
a path I want to embark on in isolation, when we have proxy and
subrequest code already there.
When I wrote that, I did look at the existing code, but reusing it
seemed more trouble than it was worth (this was before last year's
major refactoring of the proxy, FWIW). AFAICT none of the existing
modules exports an API for it.
My code is basically HTTP/1.1 with keepalives and connection pooling,
but no asynchronous operation. It's also DIY-with-fudges, and bugs
like not supporting HTTP 3xx responses that aren't redirects.
I think libcurl offers much richer capabilities, doesn't it?
So, is it time we introduced a general-purpose apr_http_client?
I'd be prepared to offer my code as a startingpoint, but I'd rather
not take the driving seat for further development and documentation.
Alternatively, maybe someone could post an executive summary of the
problems and benefits of standardising on libcurl?
--
Nick Kew
#ifndef APX_HTTP
#define APX_HTTP
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
typedef struct apx_http_entity apx_http_entity ;
typedef struct apx_http_request apx_http_request ;
typedef struct apx_http_response apx_http_response ;
typedef struct apx_http_connection apx_http_connection ;
typedef struct apx_http_connection_pool apx_http_connection_pool ;
struct apx_http_entity {
const char* type ;
size_t length ;
void* data ;
} ;
typedef enum {
HTTP_NONE ,
HTTP_READY ,
HTTP_SENDING_FIXED_DATA ,
HTTP_SENDING_CHUNKED_DATA ,
HTTP_REQUEST_SENT ,
HTTP_READING_DATA ,
HTTP_READING_FIXED_DATA ,
HTTP_READING_CHUNKED_DATA ,
HTTP_ERROR
} apx_conn_state_t ;
#define BUFLEN 4096
struct apx_http_connection {
const char* host ;
int port ;
apx_conn_state_t state ;
int is_proxy ;
apr_socket_t* sock ;
unsigned int timeout ;
size_t length ;
size_t bytes ;
size_t header_bytes ;
size_t clen ;
char buf[BUFLEN] ;
char savebuf[16] ;
} ;
struct apx_http_connection_pool {
const char* proxy_host ;
int proxy_port ;
union {
apx_http_connection* proxy_conn ;
apr_hash_t* connections ;
} conn ;
} ;
struct apx_http_request {
const char* method ;
apr_uri_t uri ;
apr_table_t* headers ;
int sent ;
const char* errmsg ;
apx_http_entity* contents ;
} ;
struct apx_http_response {
int status ;
const char* reason ;
apr_table_t* headers ;
};
int apx_uri_resolve_relative(apr_pool_t *p,
const apr_uri_t *base, apr_uri_t *uptr);
int apx_uri_parse_relative(apr_pool_t *p,
const apr_uri_t *base, const char* uri, apr_uri_t* uptr);
const char* apx_http_new_request(apr_pool_t* pool, apx_http_request* req,
const char* method, const char* url, const apr_uri_t* base) ;
apx_http_connection* apx_http_make_connection(apr_pool_t* pool,
apx_http_connection_pool* connpool, apx_http_request* req) ;
void apx_http_connection_set_timeout(apx_http_connection* conn, unsigned int timeout) ;
void apx_http_send(apx_http_connection* conn, const char* str) ;
const char* apx_http_send_request(apr_pool_t* pool, apx_http_request* req,
apx_http_connection* conn) ;
const char* apx_http_get_response(apr_pool_t* pool, apx_http_connection* conn,
apx_http_response* resp) ;
apx_http_connection_pool* apx_http_new_connection_pool(apr_pool_t* pool,
const char* host, int port) ;
apr_status_t apx_http_close_connection(void* conn) ;
apr_bucket* apx_http_get_data(apr_pool_t* pool, apr_bucket_alloc_t* alloc,
apx_http_connection* conn) ;
const char* apx_http_do(apr_pool_t* pool, apx_http_connection_pool* cpool,
const char* method, const char* url, const apr_uri_t* base,
apx_http_connection** connp, apx_http_response* resp,
apr_bucket_alloc_t* alloc, int depth) ;
#endif
Re: mod_cache wishlist
On Wed, Aug 24, 2005 at 09:18:54AM -0500, Parin Shah wrote: > > > I have fixed that memory leak problem. also added script to include > > > libcurl whenever this module is included. > > > > I hope that it doesn't mean that libcurl is going to be a permanent > > solution, when subrequests (with minor changes) could serve the same > > purpose. > > Certainly not, We would have mod-c-requester which uses sub-requests > and not libcurl eventually. but my initial reaction after going > through the subrequest code was that it may require significant > refactoring. Will it work if you mark the subrequests as proxy requests? IE, the same approach as mod_rewrite and the P flag. It introduces a dependency on mod_proxy, but curl introduces a dependency on libcurl, so that's not so bad. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: mod_cache wishlist
> > I have fixed that memory leak problem. also added script to include > > libcurl whenever this module is included. > > I hope that it doesn't mean that libcurl is going to be a permanent > solution, when subrequests (with minor changes) could serve the same > purpose. Certainly not, We would have mod-c-requester which uses sub-requests and not libcurl eventually. but my initial reaction after going through the subrequest code was that it may require significant refactoring. > > BTW: if subrequests are refactored, isn't it better to move them to > APR/APR-UTIL? > Not too sure about this. let us wait for other guys' opinions. > In any case, thanks for the great contribution! > -- > Eli Marmor > [EMAIL PROTECTED] > Netmask (El-Mar) Internet Technologies Ltd. > __ > Tel.: +972-9-766-1020 8 Yad-Harutzim St. > Fax.: +972-9-766-1314 P.O.B. 7004 > Mobile: +972-50-5237338 Kfar-Saba 44641, Israel >
Re: What happened to the "Apache 2 cross reference"?
thanks for the suggestion, I'll see what I can do :-)
Re: What happened to the "Apache 2 cross reference"?
Rachel Willmer wrote: Try searching for apr_pstrdup, you'll get 154 matches. Indeed. But if you know the name of the function, you probably have no need to search. But that's interesting, I hadn't realised that doxygen's search only does full-word matching. In which case, I'll probably replace it with another search facility soon which does partial searching too. Aha! For myself, I've always found reading the headers easier than the docs generated from them. That's using grep as a default search tool, and others where appropriate. I thought from your first post and a brief look that you'd provided a fancy frontend, but I didn't realise it was supposed to do more. Anyway, to be really useful, you'd want not just apr_pstrdup and strdup, but also variants people might guess, like apr_strdup, ap_strdup and ap_pstrdup. That could IMO turn your contribution from a mere nice to something great! -- Nick Kew
