Re: [RELEASE CANDIDATE] Apache-Test-1.27 RC
Philip M. Gollucci wrote: I've noticed we include the RELEASE file in the release tarball. I don't believe mod_perl or apreq do. Is this intentional ? Appologies, this was not correct. Too many directories of this thing. -- END What doesn't kill us can only make us stronger. Nothing is impossible. Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198 Consultant / http://p6m7g8.net/Resume/ Senior Developer / Liquidity Services, Inc. http://www.liquidityservicesinc.com http://www.liquidation.com http://www.uksurplus.com http://www.govliquidation.com http://www.gowholesale.com
Re: towards a 2.07 release
On Wed, 5 Oct 2005, Steve Hay wrote: Joe Schaefer wrote: [ ... ] IMO submit a tested patch to libapreq's Param.xs that does this (where MY_PLATFORM is suitably defined to match the above): #ifdef MY_PLATFORM #undef PerlLIO_link #define PerlLIO_link(oldname, newname) win32_link(oldname, newname) #endif OK, patch attached does exactly that. With this patch in place libapreq2-2.07-rc1 now builds without error, and all tests pass too. (This is using perl-5.8.7, apache-2.0.54 and mod_perl-2.0.1 on WinXP with VC++ 6.) Thanks, Steve! Applied to apreq as 306508. -- best regards, randy
Re: make_cert.sh?
William A. Rowe, Jr. wrote: Folks, should we restore the missing feature to actually help folks create their first cert/key with a support/ .sh/.bat file to generate a key and a cert? No, I think we should give a URL to our online documentation that tells you how. -Paul
Re: make_cert.sh?
Paul Querna wrote: William A. Rowe, Jr. wrote: Folks, should we restore the missing feature to actually help folks create their first cert/key with a support/ .sh/.bat file to generate a key and a cert? No, I think we should give a URL to our online documentation that tells you how. That's one solid, and objective suggestion. After all, openssl, for all it's wrinkles, is really not that hard to use... ...anyone on the Docs team want to write something up? There's really no call for an offsite link. Bill
Re: make_cert.sh?
William A. Rowe, Jr. wrote: Paul Querna wrote: William A. Rowe, Jr. wrote: Folks, should we restore the missing feature to actually help folks create their first cert/key with a support/ .sh/.bat file to generate a key and a cert? No, I think we should give a URL to our online documentation that tells you how. That's one solid, and objective suggestion. After all, openssl, for all it's wrinkles, is really not that hard to use... ...anyone on the Docs team want to write something up? There's really no call for an offsite link. I agree, we should make it part of our docs. We already have: http://httpd.apache.org/docs/2.1/ssl/ssl_faq.html#aboutcerts All the ideas are there, it just needs to be distilled into a simple page with the steps for key generation and where to get more info (That FAQ, other mod_ssl docs?) On a separate note, several things inside the SSL FAQ are completely outdated and seem to only apply to 1.3... -Paul
Re: make_cert.sh?
On Wed, Oct 05, 2005 at 01:10:18AM -0500, William A. Rowe, Jr. wrote: should we restore the missing feature to actually help folks create their first cert/key with a support/ .sh/.bat file to generate a key and a cert? I wouldn't mind that. Alternatively adding a version of sign.sh to support/ would be useful too, not automating the process as much as some people has previously argued against, but still keeping the process of signing certs fairly simple. Whatever we end up with, I'll work on getting that into our docs before 2.2 is released. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: [PATCH] ProxyRemote + ProxyBlock oddness
On 10/3/05, Eric Covener [EMAIL PROTECTED] wrote: On 6/15/05, Jeff Trawick [EMAIL PROTECTED] wrote: On 4/25/05, Eric Covener [EMAIL PROTECTED] wrote: I've attached a patch that resolves the hostname in the URI and hands that off separately to ap_proxy_checkproxyblock(). Any comments from the peanut gallery, particularly the proxy portion? Just revisiting this issue that still appears in 2.1.8...when proxying by way of another proxy (ProxyRemote), httpd will compare that ProxyRemote backend address to the list of ProxyBlocks. It should compare the address in the URI. unclear to me that uri_addr is always set in this patch (probably I'm confused, but hints would be appreciated)
Re: Release plans?
måndag 03 oktober 2005 18.35 skrev Paul Querna: Oden Eriksson wrote: Hi. I don't know if this is the right forum for this question but I found no info elsewhere. I simply wonder when 2.1.x is going to be dubbed stable? See our versioning file: http://svn.apache.org/repos/asf/httpd/httpd/trunk/VERSIONING 2.1.x will never be 'stable'. Your question should be, 'I simply wonder when 2.2.0 is going to be released?' Ahh, sorry. I meant 2.2.x There is no simple answer. Mine is simply 'soon'. The more people that test the 2.1.x betas on more sites give us more confidence in calling it 2.2.0. We want both positive and negative reports. So, my question is to you, did you test 2.1.8-beta? Did you try some of the new features? Did it work how you expected? Do you need more documentation on how to use the new features? I packed it and uploaded it into the mandriva rep the other day. I haven't tested the new features much though. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://nux.se
[PATCH] Bug 36816: balancer_manager doesn't work if worker name contains port
Attached is a patch for bug 36816. The balancer_manager interface offered by mod_proxy_balancer doesn't work properly if a worker name contains a port number. E.g. if I have configured a cluster as: Proxy balancer://testcluster BalancerMember http://server-one.mydomain.com:1234 BalancerMember http://server-two.mydomain.com:1234 /Proxy then I'm not able to edit the worker settings via the balancer_manager. This is because the worker-name is being compared to worker-hostname; worker-name contains the port and worker- hostname does not. I've created the patch below to fix this problem. --Colin balancer_diff Description: Binary data
3700 core files for mod_mbox
This is my period reminder email that mod_mbox is regularly crashing on ajax. Nothing more to add from my previous notes. Joshua.
What is a REQUEST?
In order to continue with our efforts to make http a truly flexible multiprotocol server, we need to start distinguishing a few elements. The MPM core engine, the connection rec and core filters are (or should have been) request_rec agnostic. The act of establishing a connection has nothing to do with a request-oriented paradime. I propose to leave everything that is request-agnostic in server/... The request_rec happens to be http-specific now, but really doesn't need to be. However, the request/response pattern is useful to a number of various protocols, so I propose to create a new directory of all of the request_rec specific core elements, as request/... I envision every build of httpd binary would include all of server/ and all of request/, even if the protocols the user wishes to use don't acutally use the request paradime. This ensures they can then load some request-oriented protocol module and we don't end up with some silly util_request.so module. After splitting off all request_rec common functionality, we then again need to refactor between request/... and modules/http/... - there are many many examples where the relationships between the two are nonsense. At this time, this process will have -very- few side effects. The only code patches will be to factor out spurrious references to request_rec where they were never appropriate within connection modules, and move that identical behavior to the appropriate spot in the request/... code. The only impact for the module author will be that some request noise will have moved, and if they wish to use connection API's - those will be available to request_rec-less protocol modules. Bill
httpd-trunk - autoconf garbage
found apr source: /local0/asf/apr-1.2 found apr-util source: /local0/asf/aprutil-1.2 copying build files rebuilding srclib/pcre/configure rebuilding include/ap_config_auto.h.in configure.in:317: warning: AC_RUN_IFELSE was called before AC_AIX autoconf/specific.m4:427: AC_AIX is expanded from... configure.in:317: the top level configure.in:319: warning: AC_RUN_IFELSE was called before AC_MINIX autoconf/specific.m4:446: AC_MINIX is expanded from... configure.in:319: the top level rebuilding configure configure.in:317: warning: AC_RUN_IFELSE was called before AC_AIX autoconf/specific.m4:427: AC_AIX is expanded from... configure.in:317: the top level configure.in:319: warning: AC_RUN_IFELSE was called before AC_MINIX autoconf/specific.m4:446: AC_MINIX is expanded from... configure.in:319: the top level Could whoever introduced this determine how to properly fix it?
Re: httpd-trunk - autoconf garbage
On Wed, Oct 05, 2005 at 03:04:52PM -0500, William A. Rowe, Jr. wrote: Could whoever introduced this determine how to properly fix it? My bad, fixed now. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Our own home on freenode.net
Folks, it seems that the #apr channel (a great place to hang out) seems to be detoured frequently into off-topic other-project traffic (including a bogus redirect of [EMAIL PROTECTED] commits at that channel.) since nothing else quite fit, and I sure didn't want alot of end user traffic, a new #httpd-dev channel exists for those fighting through the muck and mire of keeping httpd/trunk/ building. please, remember that IRC is not a substitute for the mailing list, votes must happen here, decisions must be discussed here, and ideally, if you brainstorm something cool on #httpd-dev, post the recap here. otherwise, just a fun/friendly place to hang out for httpd'ers, so feel free to drop by. Bill
Re: Our own home on freenode.net
On Wednesday 05 October 2005 21:57, William A. Rowe, Jr. wrote: Folks, it seems that the #apr channel (a great place to hang out) seems to be detoured frequently into off-topic other-project traffic (including a bogus redirect of [EMAIL PROTECTED] commits at that channel.) since nothing else quite fit, and I sure didn't want alot of end user traffic, a new #httpd-dev channel exists for those fighting through the muck and mire of keeping httpd/trunk/ building. please, remember that IRC is not a substitute for the mailing list, votes must happen here, decisions must be discussed here, and ideally, if you brainstorm something cool on #httpd-dev, post the recap here. otherwise, just a fun/friendly place to hang out for httpd'ers, so feel free to drop by. Hmmm. I'm not really convinced we need another channel. We already have #apache-modules, which deals with httpd (as well as module) hacking, and has largely the same membership as #apr (and modest traffic - we don't generally have a problem keeping helpdesk traffic to #apache:-) -- Nick Kew
Re: Our own home on freenode.net
Nick Kew wrote: I'm not really convinced we need another channel. We already have #apache-modules, which deals with httpd (as well as module) hacking, and has largely the same membership as #apr (and modest traffic - we don't generally have a problem keeping helpdesk traffic to #apache:-) one nice aspect, once chipig reconfigures the noise from the CIA bot, will be monitoring httpd commit traffic on #httpd-dev. So as you point out, #apache-modules is a nice place to hang out without that extra noise. Bill
[STATUS] (httpd-test: flood) Wed Oct 5 23:51:52 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 Oct 5 23:53:04 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.1) Wed Oct 5 23:50:14 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=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? 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-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 +1: wsanchez (propose sysconfdir/examples/version 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: * Patches submitted to
Re: svn commit: r306495 - in /httpd/httpd/trunk: include/ap_mmn.h include/http_core.h modules/http/http_core.c server/core.c server/core_filters.c server/protocol.c
On Oct 5, 2005, at 7:04 PM, William A. Rowe, Jr. wrote:
Before I consider backporting for 2.1-dev, I'd very much appreciate
if some of the event mpm ap_process_http_async_connection developers
would confirm that the mechanisms behave the way I expect them to.
IIUC, the event pollset will handle the core timeout, and the
keep_alive_timeout on their own, and the common code to read-between
the request line and headers, headers and body follow the normal
course
of processing as in the non-async model.
Yes, that's how things currently work in the event MPM in 2.2 and
the 2.3 trunk. Strictly speaking, the common code handles the core
timeout, and the MPM's pollset only has to handle the keepalive
timeout. When we add async write completion, the MPM can apply
the core write timeout itself.
On the async-dev branch, my ap_core_output_filter() rewrite
currently does a hack in order to achieve nonblocking writes:
if (nonblocking) {
get the socket's timeout (as set by the NET_TIME filter)
clear the timeout
do the write
restore the timeout value
}
else {
do the blocking write, relying on the timeout set in NET_TIME
}
I'll have to modify the code to figure out for itself what the
timeout should be (rather than looking up a value that the
NET_TIME filter has set in the socket). But that's no problem;
the resulting code will be cleaner than the current hack.
Brian
