Re: httpd-proxy-scoreboard
Ruediger Pluem wrote: On 07/26/2006 10:53 PM, Jean-frederic Clere wrote: I already have a prototype of an external health checker process that uses an AJP cping/cpong and a simple connect for http/https. Basicaly mod_proxy uses the health_worker_method routine to write and read from a slot mem that contains the information of the workers + a health information. A balancer could check the health information before using the worker. The health checker process uses the worker description (thru the health_worker_method) to check if the back-end service is running. Sorry, you may have explained that before, but why using an external health checker process? The idea is to have the health check independant from the requests so that httpd knows in advance that a worker is not working. My thoughts are more the line to do a health check on a connection every time you lease it from the pool. That means you try a worker that may be down since a while (x seconds). If I use something request driven, tell check every x seconds I would like to check all workers, how to do that without slowing down the request that causes the health check? I will make a try ;-) Cheers Jean-Frederic Regards Rüdiger
Re: httpd-proxy-scoreboard
On 07/27/2006 11:31 AM, Jean-frederic Clere wrote: Ruediger Pluem wrote: On 07/26/2006 10:53 PM, Jean-frederic Clere wrote: I already have a prototype of an external health checker process that uses an AJP cping/cpong and a simple connect for http/https. Basicaly mod_proxy uses the health_worker_method routine to write and read from a slot mem that contains the information of the workers + a health information. A balancer could check the health information before using the worker. The health checker process uses the worker description (thru the health_worker_method) to check if the back-end service is running. Sorry, you may have explained that before, but why using an external health checker process? The idea is to have the health check independant from the requests so that httpd knows in advance that a worker is not working. Ah, now I get it. Ok, I guess we both have slightly different ideas about what to health check. Your idea is more of a server health check and is somewhat similar to what HW loadbalancers are doing: Check each backend on a regular schedule if it is still available. My idea is more of a connection health check. I want to check if the connection I leased from the pool is still healthy. If it is not that does not mean necessarily that the server in the backend failed. It could be just this connection. So the default response on a faulty connection would be to close this one and try with a new one. Only if this fails also then there seems to be something wrong with the backend server. This is more like what most DB connection pools offer with a health-check query. I think both ideas make sense. Of course the connection health checks should be simpler than the server health check to avoid too much overhead and too much lost time. That is the reason why I think that e.g. doing a HTTP request on a HTTP connection leased from the pool is unreasonable. We need some quick network layer check in this case, whereas in the AJP case CPING/CPONG has still an acceptable overhead. Finally I think if we have a good provider interface we can use the health check providers for both kind of health checks. We only need to create the frameworks for them to start in different parts of the code (separate process in your case, in my case I would guess that it needs to replace is_socket_connected which is called from ap_proxy_connect_backend) Regards Rüdiger
Re: httpd-proxy-scoreboard
Ruediger Pluem wrote: On 07/27/2006 11:31 AM, Jean-frederic Clere wrote: Ruediger Pluem wrote: On 07/26/2006 10:53 PM, Jean-frederic Clere wrote: I already have a prototype of an external health checker process that uses an AJP cping/cpong and a simple connect for http/https. Basicaly mod_proxy uses the health_worker_method routine to write and read from a slot mem that contains the information of the workers + a health information. A balancer could check the health information before using the worker. The health checker process uses the worker description (thru the health_worker_method) to check if the back-end service is running. Sorry, you may have explained that before, but why using an external health checker process? The idea is to have the health check independant from the requests so that httpd knows in advance that a worker is not working. Ah, now I get it. Ok, I guess we both have slightly different ideas about what to health check. Your idea is more of a server health check and is somewhat similar to what HW loadbalancers are doing: Check each backend on a regular schedule if it is still available. Yep. My idea is more of a connection health check. I want to check if the connection I leased from the pool is still healthy. You want to check all the connections of the pool corresponding to the worker but not all the workers. If it is not that does not mean necessarily that the server in the backend failed. That probably means the socket has been closed ;-) It could be just this connection. So the default response on a faulty connection would be to close this one and try with a new one. With TC that means you create a new thread in TC, we must not overload the back-end server. Only if this fails also then there seems to be something wrong with the backend server. This is more like what most DB connection pools offer with a health-check query. I think both ideas make sense. Of course the connection health checks should be simpler than the server health check to avoid too much overhead and too much lost time. That is the reason why I think that e.g. doing a HTTP request on a HTTP connection leased from the pool is unreasonable. Yes... That is hard to check if http/https back-end server is healthy or not. We need some quick network layer check in this case, whereas in the AJP case CPING/CPONG has still an acceptable overhead. Finally I think if we have a good provider interface we can use the health check providers for both kind of health checks. Right an internal httpd provide would have the 2 health checks ways and external one probably one. If the health check is external we only need to process the result, if it is internal both health check and result processing are needed. We only need to create the frameworks for them to start in different parts of the code (separate process in your case, in my case I would guess that it needs to replace is_socket_connected which is called from ap_proxy_connect_backend) Regards Rüdiger
CacheEnable and forward proxy
sorry if this is a double post - I was not subscribed to [EMAIL PROTECTED] when I sent this the 1st time...I am doing some work with Apache 2.2.2 (currently testing win32) and am running into some problems with CacheEnable and proxy requests. My ultimate goal is to cache only proxy requests (with mod_disk_cache), but right now I am running into problems with the basic scenario of just http proxied url's. The 2.2 CacheEnable documentation lists the following example:# Cache content from www.apache.orgCacheEnable disk http://www.apache.org/ This works as expected (caches proxy requests to apache.org). If I then change it to: CacheEnable disk http://My same proxy request to http://www.apache.org does not get cached on my server. The debug level error log does not list the cache save filter as ever being added (while it does when I use CacheEnable disk http://www.apache.org/ ), so I never am able to see why the request to the url was not cached. Should this not be cached? I see the same example in the CacheEnable 2.2 doc for proxied ftp requests (CacheEnable disk ftp://).I know an easy solution to caching only proxy requests would be to put the catch all 'CacheEnable disk /' in a virtual host - but I need to be able to cover the scenario of when a customer wants to only cache proxy requests, and specifies it in the server context. Should 'cacheenable disk http://' be caching all forward http proxy requests? Before filing a bug I wanted to make sure it wasn't working as designed for 2.2.thanks,Ryan
Re[2]: apache 2.2 crashes at the start time in mod_dbd.c then preparing AuthDBDUserPWQuery
Hello Nick,
I did some tests again with mod_dbd, but now against trunk versions of
httpd, apr, apr-utils. And it seems to me, that the problem persists.
It crashes with the same symptoms as I posted last week.
Function ap_dbd_prepare called with corrupted arguments (s=0x80e6ed0,
query=0x,
label=0x), which led to crash in apr_hashfunc_default
(char_key=0x0, klen=0xbfbfe2c0).
My previous post about soft prepare problem looks to be irrelevant.
Internal error: DBD: failed to initialise prepared SQL statements
seems to be a back-side of corrupted but not crashed query handler.
I included httpd.conf, gdb output and my compilation options.
I would be glad to hear, that something is wrong with my environment
(e.g. compilation, configuration etc), but I couldn't find anything I
can fix.
Anton Golubev
ENGECON
St. Petersburg
P.S. Regarding autoconf for APR-Utils. Mysql detection has been fixed
by Bojan a month ago in trunk version. So my patches are a bit outdated.
Bojan also uses mysql-config to determine path to the libraries.
The current status: it's broken in 1.2.7, but fixed in not yet
released 1.3.0.
(gdb) file ./httpd
Reading symbols from ./httpd...done.
(gdb) run
Starting program: /usr/home/anton/work/apache22/bin/httpd
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 100698)]
apr_hashfunc_default (char_key=0x0, klen=0xbfbfe2c0) at tables/apr_hash.c:228
228 for (p = key; *p; p++) {
(gdb) bt
#0 apr_hashfunc_default (char_key=0x0, klen=0xbfbfe2c0) at
tables/apr_hash.c:228
#1 0x88262bbe in find_entry (ht=0x812e018, key=0x0, klen=-1, val=0x0) at
tables/apr_hash.c:260
#2 0x88262d92 in apr_hash_get (ht=0x, key=0xbfbfe2c0, klen=-1) at
tables/apr_hash.c:330
#3 0x0807cde3 in ap_dbd_prepare (s=0x80e6ed0, query=0x Error reading
address 0x: Bad address,
label=0x Error reading address 0x: Bad address) at
mod_dbd.c:152
#4 0x0807a5a5 in authn_dbd_prepare (cmd=0xbfbfe6a0, cfg=0x8128d60,
query=0x8128d68 select PASS from Users where LOGIN=%s) at mod_authn_dbd.c:70
#5 0x08072827 in invoke_cmd (cmd=0x80a79a0, parms=0xbfbfe6a0,
mconfig=0x8128d60, args=0x81283bf ) at config.c:788
#6 0x080730ac in ap_walk_config (current=0x8128378, parms=0xbfbfe6a0,
section_vector=0x8128960) at config.c:1141
#7 0x0806aff4 in dirsection (cmd=0xbfbfe6a0, mconfig=0x8123648, arg=0x8128beb
) at core.c:1784
#8 0x08072827 in invoke_cmd (cmd=0x80a5440, parms=0xbfbfe6a0,
mconfig=0x8123648, args=0x8128298 /home/anton) at config.c:788
#9 0x080730ac in ap_walk_config (current=0x8128278, parms=0xbfbfe6a0,
section_vector=0x81225a8) at config.c:1141
#10 0x08073b92 in ap_process_config_tree (s=0xbfbfe2c0, conftree=0x8128078,
p=0x80dc018, ptemp=0x) at config.c:1743
#11 0x08061fcb in main (argc=1, argv=0xbfbfe7c8) at main.c:641
(gdb) up
#1 0x88262bbe in find_entry (ht=0x812e018, key=0x0, klen=-1, val=0x0) at
tables/apr_hash.c:260
260 hash = ht-hash_func(key, klen);
(gdb) up
#2 0x88262d92 in apr_hash_get (ht=0x, key=0xbfbfe2c0, klen=-1) at
tables/apr_hash.c:330
330 he = *find_entry(ht, key, klen, NULL);
(gdb) up
#3 0x0807cde3 in ap_dbd_prepare (s=0x80e6ed0, query=0x Error reading
address 0x: Bad address,
label=0x Error reading address 0x: Bad address) at
mod_dbd.c:152
152 prepared-next = apr_hash_get(dbd_prepared_defns,
s-server_hostname,
(gdb) l
147 const char *label)
148 {
149 dbd_prepared *prepared = apr_pcalloc(s-process-pool,
sizeof(dbd_prepared));
150 prepared-label = label;
151 prepared-query = query;
152 prepared-next = apr_hash_get(dbd_prepared_defns,
s-server_hostname,
153 APR_HASH_KEY_STRING);
154 apr_hash_set(dbd_prepared_defns, s-server_hostname,
APR_HASH_KEY_STRING,
155 prepared);
156 }
(gdb) up
#3 0x0807cde3 in ap_dbd_prepare (s=0x80e6ed0, query=0x Error reading
address 0x: Bad address,
label=0x Error reading address 0x: Bad address) at
mod_dbd.c:152
152 prepared-next = apr_hash_get(dbd_prepared_defns,
s-server_hostname,
[EMAIL PROTECTED] uname -a
FreeBSD bill.engec.ru 5.4-STABLE FreeBSD 5.4 #1: Tue Aug 23 23:38:37 MSD 2005
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BILL-SMP i386
#! /bin/sh
#
# Created by configure
./configure \
--prefix=/home/anton/work/apache22 \
--enable-so \
--enable-dbd \
--enable-authn-dbd \
$@
[EMAIL PROTECTED] svn info ./mod_dbd.c
Path: mod_dbd.c
Name: mod_dbd.c
URL:
http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/database/mod_dbd.c
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 426127
Node Kind: file
Schedule: normal
Last Changed Author: niq
Last Changed Rev: 424798
Last Changed Date: 2006-07-24 00:22:57 +0400 (Mon, 24 Jul
Re: svn commit: r425677 - /httpd/httpd/branches/2.2.x/STATUS
Nick, On Jul 26, 2006, at 1:40 AM, [EMAIL PROTECTED] wrote: Modified: httpd/httpd/branches/2.2.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS? rev=425677r1=425676r2=425677view=diff == --- httpd/httpd/branches/2.2.x/STATUS (original) +++ httpd/httpd/branches/2.2.x/STATUS Wed Jul 26 01:40:24 2006 @@ -103,6 +103,10 @@ Fix brokenness on certain platforms when building with -DDEBUG. http://svn.apache.org/viewvc?view=revrevision=381783 +1 sctemme, fielding + -1 niq: Why are we hacking a third-party package as bundled, + rather than upstream? This has potential for chaos + for modules (and we have a history of PCRE trouble) + as well as a maintenance nightmare! Have you reviewed the patch? This is a small modification that takes unsupported code out of the compile path when building with -DDEBUG. I have this in all my working copies. It does not break the PCRE interface. In the following message to [EMAIL PROTECTED], PCRE author Philip Hazel all but admits forgetting to ifdef these calls out in this file (which gets #included from pcre.c only if DEBUG is #defined): http://mail-archives.apache.org/mod_mbox/httpd-dev/200504.mbox/% [EMAIL PROTECTED] This just makes it easier for folks to build debug builds and help us out: http://mail-archives.apache.org/mod_mbox/httpd-dev/200604.mbox/% [EMAIL PROTECTED] The real solution of course, is to upgrade to the current release of PCRE, version 6.7. However, we should probably not do that on the stable branches. Please reconsider your bale. S. -- [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
Re: svn commit: r425677 - /httpd/httpd/branches/2.2.x/STATUS
On Thu, Jul 27, 2006 at 10:36:00AM -0700, Sander Temme wrote: ... The real solution of course, is to upgrade to the current release of PCRE, version 6.7. However, we should probably not do that on the stable branches. Agreed. Given that the pcre already shipped and in the tree is patched it's a bit late to start vetoing shipping a patched pcre. Selectively applying patches here seems absolutely fine. joe
[VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [ ] apache_1.3.37 [ ] httpd-2.0.59 [ ] httpd-2.2.3 Many thanks in advance, your humble RM, Bill
Re: svn commit: r426185 - in /httpd/httpd/branches/1.3.x: STATUS src/CHANGES src/include/httpd.h
On Jul 27, 2006, at 11:21 AM, [EMAIL PROTECTED] wrote: #define SERVER_BASEVENDOR Apache Group #define SERVER_BASEPRODUCT Apache -#define SERVER_BASEREVISION 1.3.37 +#define SERVER_BASEREVISION 1.3.38-dev What, no Apache 1337 ? Uncool! S. -- [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
Re: svn commit: r426185 - in /httpd/httpd/branches/1.3.x: STATUS src/CHANGES src/include/httpd.h
I had caught that already... in the tag; #define APACHE_RELEASE 10337100 in trunk; #define APACHE_RELEASE 10338000 we should be cool. Sander Temme wrote: On Jul 27, 2006, at 11:21 AM, [EMAIL PROTECTED] wrote: #define SERVER_BASEVENDOR Apache Group #define SERVER_BASEPRODUCT Apache -#define SERVER_BASEREVISION 1.3.37 +#define SERVER_BASEREVISION 1.3.38-dev What, no Apache 1337 ? Uncool! S.
Re: svn commit: r426143 - /httpd/httpd/branches/2.2.x/NOTICE
On Jul 27, 2006, at 10:06 AM, [EMAIL PROTECTED] wrote: Author: wrowe Date: Thu Jul 27 10:06:27 2006 New Revision: 426143 URL: http://svn.apache.org/viewvc?rev=426143view=rev Log: Wrong project name That line is for the product name, not the project name. Roy
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
+1 for release for the 2.0.59 and 2.2.3 tarballs - thanks for RMing! testall passes for both on: PASS: RHEL3/i686 RHEL4/i686 FC4/i686 FC5/i686 RHEL4/x86_64 FC5/x86_64 joe
Re: svn commit: r426143 - /httpd/httpd/branches/2.2.x/NOTICE
Roy T. Fielding wrote: On Jul 27, 2006, at 10:06 AM, [EMAIL PROTECTED] wrote: Author: wrowe Date: Thu Jul 27 10:06:27 2006 New Revision: 426143 URL: http://svn.apache.org/viewvc?rev=426143view=rev Log: Wrong project name That line is for the product name, not the project name. And - I understood that our product is the Apache HTTP Server, not httpd. At least that's been the consensus in the docs project for the last three years. I almost wrote product - but it sounded to commercial for a commit msg. Bill
Re: svn commit: r426143 - /httpd/httpd/branches/2.2.x/NOTICE
On Jul 27, 2006, at 12:57 PM, William A. Rowe, Jr. wrote: Roy T. Fielding wrote: On Jul 27, 2006, at 10:06 AM, [EMAIL PROTECTED] wrote: Author: wrowe Date: Thu Jul 27 10:06:27 2006 New Revision: 426143 URL: http://svn.apache.org/viewvc?rev=426143view=rev Log: Wrong project name That line is for the product name, not the project name. And - I understood that our product is the Apache HTTP Server, not httpd. At least that's been the consensus in the docs project for the last three years. Well, the docs project consensus is wrong. Our main product is httpd (one of several products) and our project is Apache HTTP Server Project. Change it back, please. It isn't important enough to stop the release, but I really don't appreciate people tweaking a file that I edited myself just a couple weeks ago to contain the correct legal information. Roy
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
Build with no issues on Win32. Tested all common modules including SSL and Deflate. Made it available for testing for Win32 community at www.apachelounge.com Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, July 27, 2006 20:37 Subject: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [ ] apache_1.3.37 [ ] httpd-2.0.59 [ ] httpd-2.2.3 Many thanks in advance, your humble RM, Bill
Re: svn commit: r426143 - /httpd/httpd/branches/2.2.x/NOTICE
On Thu, Jul 27, 2006 at 01:20:51PM -0700, Roy T. Fielding wrote: Well, the docs project consensus is wrong. Our main product is httpd (one of several products) and our project is Apache HTTP Server Project. Our announcements say ``Apache HTTP Server (Apache)'', I'd prefer if we used that as the product name (and it really a matter of preference). That way, we can't be accused of not having a valid notification for an ssl-linked ab binary, when distributed as part of that product (which it is) and our notification is consistent with our own release announcments. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: svn commit: r426143 - /httpd/httpd/branches/2.2.x/NOTICE
Roy T. Fielding wrote: That line is for the product name, not the project name. And - I understood that our product is the Apache HTTP Server, not httpd. At least that's been the consensus in the docs project for the last three years. Well, the docs project consensus is wrong. Our main product is httpd (one of several products) and our project is Apache HTTP Server Project. Change it back, please. It isn't important enough to stop the release, but I really don't appreciate people tweaking a file that I edited myself just a couple weeks ago to contain the correct legal information. Well, as I read it it was the incorrect legal information based on the project's evolution and group concensus. My appologies if I'm wrong. What is wrong with this page (and the rest of the website and project files and...): http://httpd.apache.org/ Your title httpd is definately wrong. NCSA was httpd. Others ship httpd. This being Apache httpd at the very least invalidated the original NOTICE. httpd is the name of -one- binary in the Apache HTTP Server, which includes a host of other binaries (e.g. support/) and the NOTICE file you placed there applies to them all, no? I have this nagging suspicion that once again the project has offended your sensibilities while your back was turned. Please be assured it wasn't intentional, but that we had this back-and-forth for months before the -project- determined it creates the Apache HTTP Server. A recent comment to Mark reaffirms it, I didn't see your response? I'm happy to change it to whatever it is supposed to be, which is [...]? Bill
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
On 7/27/2006 at 12:37 PM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [ ] apache_1.3.37 [ ] httpd-2.0.59 [ ] httpd-2.2.3 Many thanks in advance, your humble RM, Bil +1 all NetWare Brad
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
Builds fine on Windows in Win32 and Win64 On 7/27/06, Brad Nicholes [EMAIL PROTECTED] wrote: On 7/27/2006 at 12:37 PM, in message [EMAIL PROTECTED], William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [ ] apache_1.3.37 [ ] httpd-2.0.59 [ ] httpd-2.2.3 Many thanks in advance, your humble RM, Bil +1 all NetWare Brad -- ~Jorge
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
William A. Rowe, Jr. [EMAIL PROTECTED] writes: [ ] httpd-2.2.3 +1, tested (live!) on FreeBSD 6.1 and Ubuntu breezy. -- Joe Schaefer
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
William A. Rowe, Jr. wrote: [X] httpd-2.0.59 [X] httpd-2.2.3 +1 (as an RPM) on RHEL4. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
I already reported that all is building and running fine on Win32. Only one note (not critical): The mod_authn_alias.dsp and mod_authz_owner.dsp are missing. Also they are not included in Apache.dsw and Makefile.win. I made/changed above files, only I do not know how to add them to os/win32/BaseAddr.ref How do I commit this changes ? Steffen - Original Message - From: William A. Rowe, Jr. [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Thursday, July 27, 2006 20:37 Subject: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [ ] apache_1.3.37 [ ] httpd-2.0.59 [ ] httpd-2.2.3 Many thanks in advance, your humble RM, Bill
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
William A. Rowe, Jr. wrote: Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [+1] apache_1.3.37 [+1] httpd-2.0.59 [+1] httpd-2.2.3(*) All win32 installers packaged, upon counting votes - these three are released. Website updated, files trickling through the mirrors. Thanks to all who tested so quickly on their Thursday afternoon/evening! We will transmit the announcement about 12 hours from now, 1200 GMT to permit the mirrors to catch up first. (*) In order to create the win32 -src.zip package, it was necessary to back out the change for the resource compiler that had changed /d LONG_NAME=Apache Component X to /d LONG_NAME=Apache Component X since VC6 won't accept this, and the generated command line make is broken by this change. I did not modify the .tar files, only -src.zip. The solution that will work in VisualStudio 2005 GUI Mode and the older compilers is more complex than I would introduce in a urgent release.
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
On 07/27/2006 08:37 PM, William A. Rowe, Jr. wrote: [+1] httpd-2.0.59 [+1] httpd-2.2.3 On SPARC Solaris 8 and SPARC Solaris 9 (compiled and started). Thanks for RMing. Regards Rüdiger
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
Steffen wrote: I already reported that all is building and running fine on Win32. Only one note (not critical): The mod_authn_alias.dsp and mod_authz_owner.dsp are missing. Also they are not included in Apache.dsw and Makefile.win. I made/changed above files, only I do not know how to add them to os/win32/BaseAddr.ref How do I commit this changes ? You don't - the HTTP Server project only grants commit after establishing a track record of consistent patches that apply without issue. But you can always submit a patch or - in the case of brand new files - the files themselves. See http://httpd.apache.org/dev/patches.html In this case though, I think I can pick this up pretty easily from your pointers - thank you for the alert! Bill
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
On Jul 27, 2006, at 11:37 AM, William A. Rowe, Jr. wrote: Chinese firedrill time folks. There is a vulnerability affecting mod_rewrite which this release addresses. See the recent commit activity for detail. Need your votes on the following in the usual http://httpd.apache.org/dev/dist/ +/-1 Package [+1] apache_1.3.37 [+1] httpd-2.0.59 [+1] httpd-2.2.3 Many thanks in advance, your humble RM, Gory details follow. Good signatures: [EMAIL PROTECTED] firedrill $ gpg --verify apache_1.3.37.tar.Z.asc gpg: Signature made Thu Jul 27 11:40:19 2006 PDT using RSA key ID 10FDE075 gpg: Good signature from [EMAIL PROTECTED] gpg: aka William A. Rowe, Jr. [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] [EMAIL PROTECTED] firedrill $ gpg --verify apache_1.3.37.tar.gz.asc gpg: Signature made Thu Jul 27 11:35:51 2006 PDT using RSA key ID 10FDE075 gpg: Good signature from [EMAIL PROTECTED] gpg: aka William A. Rowe, Jr. [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] [EMAIL PROTECTED] firedrill $ gpg --verify httpd-2.0.59.tar.bz2.asc gpg: Signature made Thu Jul 27 10:44:55 2006 PDT using RSA key ID 10FDE075 gpg: Good signature from [EMAIL PROTECTED] gpg: aka William A. Rowe, Jr. [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] [EMAIL PROTECTED] firedrill $ gpg --verify httpd-2.0.59.tar.gz.asc gpg: Signature made Thu Jul 27 10:44:54 2006 PDT using RSA key ID 10FDE075 gpg: Good signature from [EMAIL PROTECTED] gpg: aka William A. Rowe, Jr. [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] [EMAIL PROTECTED] firedrill $ gpg --verify httpd-2.2.3.tar.bz2.asc gpg: Signature made Thu Jul 27 10:35:57 2006 PDT using RSA key ID 10FDE075 gpg: Good signature from [EMAIL PROTECTED] gpg: aka William A. Rowe, Jr. [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] [EMAIL PROTECTED] firedrill $ gpg --verify httpd-2.2.3.tar.gz.asc gpg: Signature made Thu Jul 27 10:35:49 2006 PDT using RSA key ID 10FDE075 gpg: Good signature from [EMAIL PROTECTED] gpg: aka William A. Rowe, Jr. [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] gpg: aka [EMAIL PROTECTED] Good checksums: [EMAIL PROTECTED] firedrill $ for f in *.md5 ; do md5sum -cv $f ; done apache_1.3.37.tar.Z OK apache_1.3.37.tar.gz OK httpd-2.0.59.tar.bz2 OK httpd-2.0.59.tar.gz OK httpd-2.2.3.tar.bz2 OK httpd-2.2.3.tar.gz OK Perl-framework test results: Darwin graymalkin.sandla.org 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power Macintosh powerpc 1.3.36: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/contentlength.t 206 30.00% 6 10 14 16 18 20 t/apache/headers.t 243 12.50% 3 6 9 t/apache/pr37166.t 41 25.00% 4 t/modules/include.t791 1.27% 43 t/modules/proxy.t 132 15.38% 10-11 (1 subtest UNEXPECTEDLY SUCCEEDED), 28 tests and 19 subtests skipped. Failed 5/65 test scripts, 92.31% okay. 13/1826 subtests failed, 99.29% okay. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/contentlength.t 206 30.00% 6 10 14 16 18 20 t/apache/headers.t 243 12.50% 3 6 9 t/apache/pr37166.t 41 25.00% 4 t/modules/include.t791 1.27% 43 t/modules/proxy.t 132 15.38% 10-11 (1 subtest UNEXPECTEDLY SUCCEEDED), 28 tests and 19 subtests skipped. Failed 5/65 test scripts, 92.31% okay. 13/1826 subtests failed, 99.29% okay. No regressions. +1. 2.0.58 All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and 12 subtests skipped. Files=76, Tests=2806, 632 wallclock secs (79.91 cusr + 30.84 csys = 110.75 CPU) 2.0.59 All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and 12 subtests skipped. Files=76, Tests=2806, 297 wallclock secs (79.36 cusr + 30.39 csys = 109.75 CPU) No regressions. +1. 2.2.2 All tests successful, 3 tests and 2 subtests skipped. Files=76, Tests=2832, 809 wallclock secs (82.60 cusr + 32.56 csys = 115.16 CPU) [warning] server localhost:8529 shutdown 2.2.3 All tests successful, 3 tests and 2 subtests skipped. Files=76, Tests=2832, 308 wallclock secs (79.34 cusr + 30.91 csys = 110.25 CPU) No regressions. +1. FreeBSD bagheera.sandla.org. 6.1-STABLE FreeBSD 6.1-STABLE #5: Thu Jun 8
Re: [VOTES] please, 2.2.3, 2.0.59, 1.3.37 releases ASAP
On Fri, 28 Jul 2006, Ruediger Pluem wrote: On 07/27/2006 08:37 PM, William A. Rowe, Jr. wrote: [+1] httpd-2.2.3 Working awesome on x86 Solaris 10. Thanks for getting the updates out so quickly. - Ryan -- UNIX Administrator http://prefetch.net
