[STATUS] (httpd-test: perl-framework) Wed Dec 7 23:56:03 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:
Re: using proxy/cache for apache mirrors
On Wed, Dec 07, 2005 at 01:18:32AM -0600, William A. Rowe, Jr. wrote: Do mirrors even validate any server signature for rsync? If not this argument is blowing smoke. For that matter, we could even endorse the use of ssl privately to our mirrors on the backend, with server cert validation to avoid exactly what you describe above, as well as any number of man in the middle attacks. In fact, it seems this would be much more robust than today's rsync, in terms of security. Yep, if we could do the pull over https, that would solve this. I generally discourage ftp mirrors. But yes, they would continue to need to do rsync. Why? I'm not certain, but expect there are ways to play with wget to fetch only new/changed files. If not, perhaps it's time to teach wget some new tricks :) If you dropped rsync, we'd lose most of the mirrors. They absolutely won't be interested in that kind of poking. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: 2.2 mod_http_proxy and partial pages
-On December 7, 2005 2:00:19 AM +0100 Ruediger Pluem [EMAIL PROTECTED] wrote: The patches to mod_proxy_http we identified here on list do indeed work and are in as r354628. Sorry for stepping in that late into the discussion, but wouldn't it be better to fix that after the return from proxy_run_scheme_handler in mod_proxy? The error has to be flagged inside the HTTP scheme before the error is lost. Without this patch, mod_proxy_http returns 'success' unconditionally. That is clearly wrong and that's what I changed. Yes, of course the scheme handler must signal the proxy handler that the backend broke. Just returning 'success' in this case is of course plain wrong. I fear that mod_proxy_ajp is affected by the same problem that is now fixed in mod_proxy_http. This means we put the burden of handling this in a unified way on each proxy backend module. How about letting the schema_handler simply return a specific value (DONE or whatever) to signal that the backend broke in the middle of sending the response and let mod_proxy handle the dirty work. That's what it does right now. What would you like to change? I would like to set the c-aborted in mod_proxy's proxy_handler after the run_scheme_handler. Reason: 1. We can define a clear interface for the scheme handlers here: If the backend broke before you sent headers just return BAD_GATEWAY and send nothing, if it broke afterwards just return BROKEN_BACKEND (or whatever you like that should be defined for this case). The proxy handler would handle this BROKEN_BACKEND return code and do the 'right' thing (currently setting c-aborted). Thus we do not have the need to put the burden of the details on the schema handler (why I regard it as a burden see 2.) 2. I am not 100% percent happy with the c-aborted approach as the original intention of c-aborted was another one (The connection to the *client* broke not to the *backend*). I admit that I do not see any other approach currently, so we should stick with this, but if we decide to change this later on and we follow 1. then it is much easier to change as we have this code only in *one* location and not in every scheme handler. [..cut..] An error bucket is already sent down the chain when the specific connection error I hit with the chunked line occurs through HTTP_IN, but that accomplishes little because the HTTP filters which understand the error buckets have already gone as the headers have been sent. FWIW, an error bucket, by itself, would not be enough; the connection close logic is only implemented well outside of the filter logic. At best, it has to be an error bucket combined with a returned status code that can be returned all the way up. -- justin Ahh, ok. Thanks for clarification. Regards Rüdiger
Re: Apache 2.2.0 Win64
So no-one is interested in testing? How is Apache 64bit on other systems? Did it give a preformance boost? ~Jorge
Re: 2.2 mod_http_proxy and partial pages
On Wed, Dec 07, 2005 at 10:21:10AM +0100, Plm, Rdiger, VIS wrote: I would like to set the c-aborted in mod_proxy's proxy_handler after the run_scheme_handler. Reason: 1. We can define a clear interface for the scheme handlers here: If the backend broke before you sent headers just return BAD_GATEWAY and send nothing, if it broke afterwards just return BROKEN_BACKEND (or whatever you like that should be defined for this case). The proxy handler would handle this BROKEN_BACKEND return code and do the 'right' thing (currently setting c-aborted). Thus we do not have the need to put the burden of the details on the schema handler (why I regard it as a burden see 2.) Feel free to commit a patch. =) 2. I am not 100% percent happy with the c-aborted approach as the original intention of c-aborted was another one (The connection to the *client* broke not to the *backend*). I admit that I do not see any other approach currently, so we should stick with this, but if we decide to change this later on and we follow 1. then it is much easier to change as we have this code only in *one* location and not in every scheme handler. But, that's exactly what we want: we must abort the connection to the client because we can't complete the response. -- justin
Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
On Wed, Dec 07, 2005 at 03:48:39PM -, [EMAIL PROTECTED] wrote:
+* proxy_util: Fix case where a shared keepalive connection results in
+ different (and incorrect) workers from being accessed.
+
http://svn.apache.org/viewcvs.cgi/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=350250view=diffr1=350250r2=332306
+ +1: jim
In reviewing this, I can't for the life of me figure out why there's an if
and else check that has the exact same body. Can't we just do:
if (!conn-hostname || !worker-is_address_reusable ||
(r-connection-keepalives
(r-proxyreq == PROXYREQ_PROXY || r-proxyreq == PROXYREQ_REVERSE)
(strcasecmp(conn-hostname, uri-hostname) != 0))) {
}
With a conditional like this, it'd probably be nice to have the conditional
tests in a comment so that we can understand the check that it's doing. =)
Or, am I missing something? -- justin
RE: 2.2 mod_http_proxy and partial pages
-Ursprüngliche Nachricht- Von: Justin Erenkrantz Gesendet: Mittwoch, 7. Dezember 2005 17:08 An: dev@httpd.apache.org Betreff: Re: 2.2 mod_http_proxy and partial pages [..cut..] Feel free to commit a patch. =) I will do so :). 2. I am not 100% percent happy with the c-aborted approach as the original intention of c-aborted was another one (The connection to the *client* broke not to the *backend*). I admit that I do not see any other approach currently, so we should stick with this, but if we decide to change this later on and we follow 1. then it is much easier to change as we have this code only in *one* location and not in every scheme handler. But, that's exactly what we want: we must abort the connection to the client because we can't complete the response. -- justin Yes, I know. Maybe this is nitpicking, but my original understanding is that c-aborted is set if the connection to the client has broken for whatever external reason on the network route between client and server, not if we decide that we need to / should break this connection to the client because of something has gone wrong on the backend. But as said, this is possibly just nitpicking :-). Regards Rüdiger
Re: 2.2 mod_http_proxy and partial pages
On Wed, Dec 07, 2005 at 05:24:46PM +0100, Plm, Rdiger, VIS wrote: Yes, I know. Maybe this is nitpicking, but my original understanding is that c-aborted is set if the connection to the client has broken for whatever external reason on the network route between client and server, not if we decide that we need to / should break this connection to the client because of something has gone wrong on the backend. But as said, this is possibly just nitpicking :-). Nope, that's the flag we set when we want the core to drop the connection. I thought that it would be set by the filters when a connection was dropped, but, as I said earlier in this thread, I'm wrong. The filters will never ever set it. -- justin
Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
Justin Erenkrantz wrote:
On Wed, Dec 07, 2005 at 03:48:39PM -, [EMAIL PROTECTED] wrote:
+* proxy_util: Fix case where a shared keepalive connection results in
+ different (and incorrect) workers from being accessed.
+
http://svn.apache.org/viewcvs.cgi/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=350250view=diffr1=350250r2=332306
+ +1: jim
In reviewing this, I can't for the life of me figure out why there's an if
and else check that has the exact same body. Can't we just do:
if (!conn-hostname || !worker-is_address_reusable ||
(r-connection-keepalives
(r-proxyreq == PROXYREQ_PROXY || r-proxyreq == PROXYREQ_REVERSE)
(strcasecmp(conn-hostname, uri-hostname) != 0))) {
}
The sole reason was the keep the present setup, so that if
is_address_reusable becomes more accurate we don't loose
information on what was the original intent... I'd also
prefer making it one large conditional as well, but
others were looking at the current logic and I didn't
want to change too much :)
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
On Wed, Dec 07, 2005 at 11:29:57AM -0500, Jim Jagielski wrote: The sole reason was the keep the present setup, so that if is_address_reusable becomes more accurate we don't loose information on what was the original intent... I'd also Can you please elaborate on that? Thanks. -- justin
Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
Jim Jagielski wrote:
Justin Erenkrantz wrote:
On Wed, Dec 07, 2005 at 03:48:39PM -, [EMAIL PROTECTED] wrote:
+* proxy_util: Fix case where a shared keepalive connection results in
+ different (and incorrect) workers from being accessed.
+
http://svn.apache.org/viewcvs.cgi/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=350250view=diffr1=350250r2=332306
+ +1: jim
In reviewing this, I can't for the life of me figure out why there's an if
and else check that has the exact same body. Can't we just do:
if (!conn-hostname || !worker-is_address_reusable ||
(r-connection-keepalives
(r-proxyreq == PROXYREQ_PROXY || r-proxyreq == PROXYREQ_REVERSE)
(strcasecmp(conn-hostname, uri-hostname) != 0))) {
}
The sole reason was the keep the present setup, so that if
is_address_reusable becomes more accurate we don't loose
information on what was the original intent... I'd also
prefer making it one large conditional as well, but
others were looking at the current logic and I didn't
want to change too much :)
PS: Unless add't work is done on this section within the next
few days, I'll clean up the whole section (in trunk)
to streamline things...
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
If you can dodge a wrench, you can dodge a ball.
Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
Justin Erenkrantz wrote: On Wed, Dec 07, 2005 at 11:29:57AM -0500, Jim Jagielski wrote: The sole reason was the keep the present setup, so that if is_address_reusable becomes more accurate we don't loose information on what was the original intent... I'd also Can you please elaborate on that? Thanks. -- justin Sure... Right now, there appears to be some questions on why we are treating some requests differently and how that affects the pool. Ruediger was looking into this, with the end result that some areas of this, such as what warrants a reusable connection, may be changed. I did not want to rework what was the original logic layout too much, just simply fix a quick problem. The old code has the same if-else-if structure, and I didn't want to disturb too much since Ruediger stated that this was the exact section he was playing around with. With the entry in STATUS I just didn't want the current misbehavior to continue in 2.2... -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
AW: 2.2 mod_http_proxy and partial pages
-Ursprüngliche Nachricht- Von: Justin Erenkrantz Gesendet: Mittwoch, 7. Dezember 2005 17:30 An: dev@httpd.apache.org Betreff: Re: 2.2 mod_http_proxy and partial pages On Wed, Dec 07, 2005 at 05:24:46PM +0100, Plm, Rdiger, VIS wrote: [..cut..] Nope, that's the flag we set when we want the core to drop the connection. I thought that it would be set by the filters when a connection was dropped, but, as I said earlier in this thread, I'm wrong. The filters will never ever set it. -- justin Ok. Then I withdraw my objections against the setting of c-aborted. I just understood its purpose wrong. Thanks for clarification. Regarding the question where to set this (in scheme_handler vs after run_scheme_handler hook in proxy handler) I will redecide once I had a more closer look on mod_proxy_ajp. Regards Rüdiger
AW: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Mittwoch, 7. Dezember 2005 17:43 An: Justin Erenkrantz Cc: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS Sure... Right now, there appears to be some questions on why we are treating some requests differently and how that affects the pool. Ruediger was looking into this, with the end result that some areas of this, such as what warrants a reusable connection, may be changed. I did not want to rework what was the original logic layout too much, just simply fix a quick problem. The old code has the same if-else-if structure, and I didn't want to disturb too much since Ruediger stated that this was the exact section he was playing around with. Yes, that was the area I wanted to play, but I had not found time so far :-(. So if you already have ideas on this feel free to move forward as I do not want to block progress due to this temporary lack of time on my side. I am sure it is possible for both of us to work on this as we share our ideas on the list anyway. Regards Rüdiger [..cut..]
Re: AW: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS
=?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VIS?= wrote: -Urspr=FCngliche Nachricht- Von: Jim Jagielski=20 Gesendet: Mittwoch, 7. Dezember 2005 17:43 An: Justin Erenkrantz Cc: dev@httpd.apache.org; [EMAIL PROTECTED] Betreff: Re: svn commit: r354779 - /httpd/httpd/branches/2.2.x/STATUS =20 Sure... Right now, there appears to be some questions on why we are treating some requests differently and how that affects the pool. Ruediger was looking into this, with the end result that some areas of this, such as what warrants a reusable connection, may be changed. I did not want to rework what was the original logic layout too much, just simply fix a quick problem. The old code has the same if-else-if structure, and I didn't want to disturb too much since Ruediger stated that this was the exact section he was playing around with. Yes, that was the area I wanted to play, but I had not found time so far = :-(. So if you already have ideas on this feel free to move forward as I do not want to block progress due to this temporary lack of time on my side. I am sure it is possible for both of us to work on this as we share our ideas on the list anyway. OK, great... what I'll do is clean up what we *have* and then we can work on what we *want* :) -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Configuration .. make it configurable. by that I mean allowing people to use LDAP or a DB to hold the configuration files, and not a flat file. This is mainly intended for large server farms. Currently the main reason for logging onto a webserver is to change it's configuration (and bounce) .. if we could reduce that to just 'bounce' it might make life easier. (or some method where it checks configs every X minutes and autobounces..removing the need to log onto the machine at all ;-) Would it be possible to use something like fam (or kqueue on FreeBSD) and have httpd notified whenever the config file changes? That would solve part of the above desire without requiring the extensive changes needed to go to a db/ldap system. OTOH, what if config loading was handled by a provider module that could then fetch the info from a file, db, ldap, whatever...
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Brandon Fosdick wrote: Would it be possible to use something like fam (or kqueue on FreeBSD) and have httpd notified whenever the config file changes? That would solve part of the above desire without requiring the extensive changes needed to go to a db/ldap system. That could be external to httpd. Just have a monitor (or in cfengine, or whatever) that when the config changes it issues a graceful restart. Simple and straight-forward. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Brandon Fosdick wrote: Would it be possible to use something like fam (or kqueue on FreeBSD) and have httpd notified whenever the config file changes? That would solve part of the above desire without requiring the extensive changes needed to go to a db/ldap system. That could be external to httpd. Just have a monitor (or in cfengine, or whatever) that when the config changes it issues a graceful restart. Simple and straight-forward. Certainly true, and I've even thought about doing just that. But it seems like a relatively simple change and it would make less work for the user/admin. And, to me at least, it seems Intuitively Correct that an app should be watching it's own config files for changes and then responding appropriately. I see this as being in the same vein as re-reading config files in response to a kill -HUP. Instead of (or in addition to) responding to a HUP signal, the app is responding to a file change event. Now that I think about it, watching for file events might help with log rotation too, since a signal wouldn't have to be sent when the files are changed.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Dec 7, 2005, at 2:01 PM, Brandon Fosdick wrote: Configuration .. make it configurable. by that I mean allowing people to use LDAP or a DB to hold the configuration files, and not a flat file. This is mainly intended for large server farms. Currently the main reason for logging onto a webserver is to change it's configuration (and bounce) .. if we could reduce that to just 'bounce' it might make life easier. (or some method where it checks configs every X minutes and autobounces..removing the need to log onto the machine at all ;-) Would it be possible to use something like fam (or kqueue on FreeBSD) and have httpd notified whenever the config file changes? That would solve part of the above desire without requiring the extensive changes needed to go to a db/ldap system. OTOH, what if config loading was handled by a provider module that could then fetch the info from a file, db, ldap, whatever... Yeah, maybe it's time to re-open this discussion... previously, whenever we thought about adding more functionality to the config file, it was discouraged because it increases the complexity of Apache for something that could more easily be done via an external process (ie: a script that reads in LDAP info and autogens a normal httpd.conf file)...
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
That could be external to httpd. Just have a monitor (or in cfengine, or whatever) that when the config changes it issues a graceful restart. Simple and straight-forward. Oops, I made a typo, and pressed save. poof there goes my website! IMO, it's a bad idea to automagically restart when the config changes. Joost
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On 12/07/2005 08:18 PM, Brandon Fosdick wrote: Brandon Fosdick wrote: [..cut..] And, to me at least, it seems Intuitively Correct that an app should be watching it's own config files for changes and then responding appropriately. I see this as being in the same vein as re-reading config -1 on this from my administrators perspective. I don't want the application to reload its configuration only because I adjusted it. Adjusting and reloading configuration are two different processes and applications that try to be smart in these situations are prone to mess things up in my experience. I have many situations where I adjust the configuration and where I want it to be reloaded at a *very* specific point of time that is well coordinated with other activities on an environment. Additionally saving of the config files in vi during editing it would result in a reload of the configuration with all its consequences *shiver*. Furthermore this job would be more complicated and painful as it looks at first glance as httpd would not only has to monitor the httpd.conf file but all included files also to make this work. [..cut..] Regards Rüdiger
PR 37145
Just a short reminder. I just got the 3rd duplicate for PR37145 ( data loss with httpd-2.0.55 reverse proxy method=post) and I remember myself that there had been additional cases that had been reported on the list. The patch is currently missing one vote for backport to 2.0.x. I know that 2.0.56 may be far off, but I just hit the drums because I want to ensure that it gets in. I remember that OtherBill tended to be positive about the patch and Joe agreed with the analysis + it is already part of 2.2.0 - The best Apache HTTP Server available. So to the ballot please :-). Regards Rüdiger
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Dec 7, 2005, at 3:04 PM, Joost de Heer wrote: That could be external to httpd. Just have a monitor (or in cfengine, or whatever) that when the config changes it issues a graceful restart. Simple and straight-forward. Oops, I made a typo, and pressed save. poof there goes my website! IMO, it's a bad idea to automagically restart when the config changes. Big +1. If someone wants some sort of external process to do this, well, then, that's their choice. But I would be a big -1 to have Apache do this itself.
AW: PR 37145
does this problem effect 2.0.55 too? -Ursprüngliche Nachricht- Von: Ruediger Pluem [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 7. Dezember 2005 21:44 An: dev@httpd.apache.org Betreff: PR 37145 Just a short reminder. I just got the 3rd duplicate for PR37145 ( data loss with httpd-2.0.55 reverse proxy method=post) and I remember myself that there had been additional cases that had been reported on the list. The patch is currently missing one vote for backport to 2.0.x. I know that 2.0.56 may be far off, but I just hit the drums because I want to ensure that it gets in. I remember that OtherBill tended to be positive about the patch and Joe agreed with the analysis + it is already part of 2.2.0 - The best Apache HTTP Server available. So to the ballot please :-). Regards Rüdiger
Re: AW: 2.2 mod_http_proxy and partial pages
Okay, so what is the status of this? Are the two patches submitted good enough for all those concerned. AFAIK, they seem to fix my issue. I would like some idea of how 2.2.1 will handle it, so I do not wind up having to patch and re-patch here. TIA -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: AW: PR 37145
On 12/07/2005 09:48 PM, Matthias Behrens wrote: does this problem effect 2.0.55 too? AFAIK it does only affect 2.0.55 of the stable releases. It is a regression from 2.0.54 caused by the very much needed changes to mod_proxy to fix CVE-2005-2088. Regards Rüdiger
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
On Wed, Dec 07, 2005 at 11:01:35AM -0800, Brandon Fosdick wrote: Would it be possible to use something like fam (or kqueue on FreeBSD) and have httpd notified whenever the config file changes? We could do the SIGIO trick which diablo does on BSD, though the problem there is that on other platform we'd end up with a tight stat() loop. It can be pretty dangerous aswell though :/ -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Joost de Heer wrote: That could be external to httpd. Just have a monitor (or in cfengine, or whatever) that when the config changes it issues a graceful restart. Simple and straight-forward. Oops, I made a typo, and pressed save. poof there goes my website! IMO, it's a bad idea to automagically restart when the config changes. Not necessarily. For instance, the FreeBSD port installs a wrapper script that checks the validity of the config files before allowing a (re)start. It even uses httpd to do the check. So, as long as httpd uses its existing validity checker to decide whether or not to do an auto-restart your website should be fine. Of course, that doesn't really help much if you made a typo that results in a valid config, but there's nothing to stop that now either.
Re: AW: 2.2 mod_http_proxy and partial pages
On Dec 7, 2005, at 8:44 AM, Plüm, Rüdiger, VIS wrote: Nope, that's the flag we set when we want the core to drop the connection. I thought that it would be set by the filters when a connection was dropped, but, as I said earlier in this thread, I'm wrong. The filters will never ever set it. -- justin Ok. Then I withdraw my objections against the setting of c-aborted. I just understood its purpose wrong. Thanks for clarification. No, you understood its purpose correctly. I have no idea what Justin is talking about -- maybe the proxy's connection to the outbound server? c-aborted is only set on the inbound connection when a previous write to that connection has failed. Setting the inbound c-aborted within a filter just to indicate that the outbound connection has died is wrong -- it prevents other parts of the server (that are working fine) from correctly handling the bad gateway response. -1 VETO Find another solution before the next release. I have no objection to such a workaround as a patch, but we don't introduce new spaghetti code just to fix a trivial problem. Roy
Apache 2.0.54(Worker) installation on RHES not working(Zombie processes on startup)
Hi, I am trying to install Apache 2.0.54 on RedHat enterprise edition, though the Installation is a succes, starting of Apache results in lots of zombie processes with no active process. Machine Information: uname -a Linux ex07 2.4.21-37.EL #1 Wed Sep 7 13:35:21 EDT 2005 i686 i686 i386 GNU/Linux more /etc/issue Red Hat Enterprise Linux AS release 3 (Taro Update 6) gcc -v gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) Installation steps: a) ./configure \--prefix=/home/shiva/apache2 \--with-mpm=worker \--enable-modules=most \--enable-mods-shared=all b) make c) make install Install is a success. on starting the server using apachectl I was able to compile and execute the same with success of sun solaris Is there some [EMAIL PROTECTED] logs]$ ../bin/apachectl start[EMAIL PROTECTED] logs]$ ps -aef | grep httpdshiva 8016 1 0 11:01 ? 00:00:00 /home/shiva/apache2/bin/httpd -k startshiva 8017 8016 0 11:01 ? 00:00:00 /home/shiva/apache2/bin/httpd -k startshiva 8018 8016 0 11:01 ? 00:00:00 /home/shiva/apache2/bin/httpd -k startshiva 8019 8018 0 11:01 ? 00:00:00 /home/shiva/apache2/bin/httpd -k startshiva 8020 8016 0 11:01 ? 00:00:00 /home/shiva/apache2/bin/httpd -k startshiva 8021 8020 0 11:01 ? 00:00:00 /home/shiva/apache2/bin/httpd -k startshiva 8023 8021 0 11:01 ? 00:00:00 /home/shiva/apache2/bin/httpd -k start I was able to compile and execute the same with success of sun solaris. But in case of RedHatES all the processes die. Is there some installation step/param which is incorrect or not mentioned? Any kind of clue would be of great help to me. Thanks in advance. shiva Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments.
Re: What do you want in HTTPD 2.4/3.0/X/GREEN?
Paul Querna wrote: My intention is for this to be a wide open brainstorming thread. I expect that we will be able to discuss several ideas in much more detail at the Hackathon next week, but I really want to get all ideas 'on the table'. Here's my list. Or at least, the partial list that comes to mind right now. Virtual Hosts: Make them less fragile, and simpler. It's just too easy to get vhosts wrong, and it's too hard to do dynamic vhosts. I would love for dynamic vhosts to be simple enough that nobody would ever be tempted to do it with mod_rewrite ever again. mod_vhost_alias does about 10% of what folks actually want. Configuration file: Something along the lines of mod_macro built in. Ability to set variables and use those variables in the configuration. A simple and usable if/else syntax. Perchild or similar. -- Rich Bowen [EMAIL PROTECTED]
[STATUS] (httpd-2.0) Wed Dec 7 23:50:50 2005
APACHE 2.0 STATUS: -*-text-*- Last modified at [$Date: 2005-12-01 20:35:16 -0500 (Thu, 01 Dec 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.56 : in development 2.0.55 : released October 16, 2005 as GA. 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=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable After testing, you can append a comment saying Reviewed and tested. * Open bugs in the bug database. CURRENT RELEASE NOTES: * Forward binary compatibility is expected of Apache 2.0.x releases, such that no MMN major number changes will occur. Such changes can only be made in the trunk. * All commits to branches/2.0.x must be reflected in SVN trunk, as well, if they apply. Logical progression is commit to trunk, get feedback and votes on list or in STATUS, then merge into branches/2.2.x, and finally merge into branches/2.0.x, as applicable. RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] *) mod_actions: Regression from 1.3: the file referred to must exist. Solve this by introducing the virtual modifier to the Action directive. PR 28553. modules/mappers/mod_actions.c: r1.32, r1.34 jerenkrantz: Icky side-effect of the *t == '0' check. +1: nd, jerenkrantz, wrowe, jim -0: by rbb (inconsistent to 1.3, discussion on dev@) nd: I'm going to reverse the default jerenkrantz, striker: I'm confused as to the status of this backport. *) support/check_forensic: Fix tempfile usage svn rev 125495, 126224 jerenkrantz says: r126224 fixes brokenness with r125495 on Solaris. +1: thommay, jerenkrantz, trawick trawick: which isn't portable; I've suggested a work-around on dev@
[STATUS] (httpd-2.1) Wed Dec 7 23:52:11 2005
APACHE 2.3 STATUS: -*-text-*- Last modified at [$Date: 2005-11-13 02:22:18 -0500 (Sun, 13 Nov 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 * http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS Release history: [NOTE that only Alpha/Beta releases occur in 2.3 development] 2.3.0 : in development 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 the bug database: http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDproduct=Apache+httpd-2.0keywords=PatchAvailable * Filter stacks and subrequests,
Re: 2.2 mod_http_proxy and partial pages
-Ursprüngliche Nachricht- Von: Roy T. Fielding Gesendet: Donnerstag, 8. Dezember 2005 03:17 [..cut..] Ok. Then I withdraw my objections against the setting of c-aborted. I just understood its purpose wrong. Thanks for clarification. No, you understood its purpose correctly. I have no idea what Justin is talking about -- maybe the proxy's connection to the outbound server? c-aborted is only set on the inbound connection when a previous write to that connection has failed. Ok. Any further opinions on the purpose of c-aborted that support either Roys or Justins point of view on this? Setting the inbound c-aborted within a filter just to indicate that the outbound connection has died is wrong -- it prevents other parts of the server (that are working fine) from correctly handling the bad gateway response. Just to ensure that we are talking about the same thing here: The client will never get aware of the bad gateway as it already has received the headers. So we are only talking about handling this bad gateway situation correctly internally, so that for example mod_cache does not cache an incomplete and thus broken response. The client is doomed anyway. As far as I can see everybody agrees that the connection to the client must be closed in this situation. Stupid question: Can't we enforce at least this by setting c-keepalive to AP_CONN_CLOSE. Of course this does not solve the problem to make the remaining parts of the code aware of the bad gateway situation. Regards Rüdiger [..cut..]
