Upcoming 2.0.56 release (?)
[Of course this message doesn't make a whole lot of sense on [EMAIL PROTECTED], reposting] AFAIK - we were simply holding on apr[-util] 0.9 to be baked. Vote is in-progress on [EMAIL PROTECTED] (in case you weren't watching that list - it might interest you to follow the low-level discussions there.) Provided that passes, and if nobody speaks quickly and loudly, I'll RM a tarball once that vote on [EMAIL PROTECTED] flies. Speak now if there are issues :) Bill
conn_rec mock up?
Hi, As of now, we can not make requests without having actual connection(conn_rec) to the server. For example, mod-cache-requester needs to make request for popular and soon-to-expire from cache pages so that these pages are reloaded in the cache. right now, it has to rely on libcurl to re-request page, which is not very elegant. other than mod-cache-requester, There are many other intersting things that can be done if we could create requests internally without requiring conn_rec. I looked over existing code, It seems, the best (and easiest) way to implement this is by mocking up conn_rec. so basically we implement one more version of core_create_conn() function which would initialize request url, sockets and various pools such that this conn_rec would work with existing request_rec. we can pass this mocked up conn_rec to make_sub_request and thus would be bale to make requests internally. any thoughts? I believe, apr_http_client would solve this problem, but I am not sure about the status of it. If anybody is working on it and dont mind if I jump into the development cycle, let me know. I would love to get my hands dirty in this problem. -Parin.
Re: Upcoming 2.0.56 release (?)
On Mon, Mar 27, 2006 at 02:26:39AM -0600, William A. Rowe, Jr. wrote: Provided that passes, and if nobody speaks quickly and loudly, I'll RM a tarball once that vote on [EMAIL PROTECTED] flies. Speak now if there are issues :) I don't know if it's implicit or not, but we shouldn't bundle unreleased libraries, so it shouldn't be enough that an apr(-util) passed the vote, it should be GA too. We need thicker chinese walls :) Just a minor change to our sometime-adopted procedure that might help non-APR httpd-committers out. I've finally deleted that patch proposal which made no sense and taken a look at some more of the proposals. Since this is our first post 2.2 GA release, do we still want feedback from infra? downgrading a.o might send some bad signals ;-) Or maybe there's a subdomain or two running 2.0 still? -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Upcoming 2.0.56 release (?)
On Monday 27 March 2006 11:07, Colm MacCarthaigh wrote: Since this is our first post 2.2 GA release, do we still want feedback from infra? downgrading a.o might send some bad signals ;-) Or maybe there's a subdomain or two running 2.0 still? Huh? Who's talking about downgrading? -- Nick Kew
Re: Upcoming 2.0.56 release (?)
On Mon, Mar 27, 2006 at 11:21:46AM +0100, Nick Kew wrote: On Monday 27 March 2006 11:07, Colm MacCarthaigh wrote: Since this is our first post 2.2 GA release, do we still want feedback from infra? downgrading a.o might send some bad signals ;-) Or maybe there's a subdomain or two running 2.0 still? Huh? Who's talking about downgrading? Until now, we've always had 3 days of 2.0 in production on ASF hardware before going GA, and I'm wondering if we now treat 2.0 like 1.3 and not do this on apache.org, or we politely ask infra to try out the candidate (I don't think there's any 2.2-only features being used on a.o). -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Upcoming 2.0.56 release (?)
On Mon, Mar 27, 2006 at 11:31:36AM +0100, Colm MacCarthaigh wrote: Until now, we've always had 3 days of 2.0 in production on ASF hardware before going GA, and I'm wondering if we now treat 2.0 like 1.3 and not do this on apache.org, or we politely ask infra to try out the candidate (I don't think there's any 2.2-only features being used on a.o). That's generally something only done for the latest and greatest - I don't think 1.3 has been tested that way for years. vh Mads Toftum -- `Darn it, who spiked my coffee with water?!' - lwall
Re: AW: Config Bug in proxy_balancer?
On Mar 23, 2006, at 9:59 AM, Plüm, Rüdiger, VIS wrote:
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I want to be able to use same balancer in multiple vhosts.
This is actually that way by design, iirc. I've no
real issues with it being Vhost specific or inheritable.
So if others think it's worthwhile having the above
functionality, I'm +1 for it and would work on something
to implement that.
+1 makes sense.
Something like this maybe? Of course, since it's inherited,
the balancer shows up twice in the balancer-manager, but
maybe that make sense :)
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c (revision 389138)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -1625,6 +1625,19 @@
conf = ap_set_config_vectors(cmd-server, new_dir_conf, cmd-path,
proxy_module, cmd-pool);
+if (strncasecmp(cmd-path, balancer:, 9) == 0) {
+ proxy_server_conf *sconf =
+ (proxy_server_conf *) ap_get_module_config(cmd-server-
module_config, proxy_module);
+proxy_balancer *balancer = ap_proxy_get_balancer(cmd-pool,
sconf, cmd-path);
+if (!balancer) {
+const char *err = ap_proxy_add_balancer(balancer,
+cmd-pool,
+sconf, cmd-path);
+if (err)
+return apr_pstrcat(cmd-temp_pool, Proxy , err,
NULL);
+}
+}
+
errmsg = ap_walk_config(cmd-directive-first_child, cmd,
new_dir_conf);
if (errmsg != NULL)
return errmsg;
Re: AW: Config Bug in proxy_balancer?
On Mar 27, 2006, at 10:27 AM, Brian Akins wrote: Jim Jagielski wrote: Something like this maybe? Of course, since it's inherited, the balancer shows up twice in the balancer-manager, but maybe that make sense :) Shouldn't it just appear once? That's just my thinking... Well, there *are* 2 balancers... but yeah, it is quite confusing, and there are things that need to be further addressed here. But we could commit as-is and tune as we go ;)
Re: AW: Config Bug in proxy_balancer?
Jim Jagielski wrote: Well, there *are* 2 balancers... but yeah, it is quite confusing, and there are things that need to be further addressed here. I'm think of what if someone had a script that parses the balancer-manager output. it would be very confusing to figure out which is the correct balancer. Any reason we can't have the limitation that balancer names must be unique? -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: AW: Config Bug in proxy_balancer?
Brian Akins wrote: Jim Jagielski wrote: Well, there *are* 2 balancers... but yeah, it is quite confusing, and there are things that need to be further addressed here. I'm think of what if someone had a script that parses the balancer-manager output. it would be very confusing to figure out which is the correct balancer. Any reason we can't have the limitation that balancer names must be unique? I don't see why not. But the reason for the double is even deeper than that. You see, the balancer is defined at the main server config rec. When each Vhost is merged, they grab a copy of the main server's balancer config setup. So you have 2 balancers, one of which isn't used at all (the main server's) and one that is. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: AW: Config Bug in proxy_balancer?
Jim Jagielski wrote: When each Vhost is merged, they grab a copy of the main server's balancer config setup. So you have 2 balancers, one of which isn't used at all (the main server's) and one that is. my very silly global_balancers patch fixes that. -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: AW: Config Bug in proxy_balancer?
Brian Akins wrote: Jim Jagielski wrote: When each Vhost is merged, they grab a copy of the main server's balancer config setup. So you have 2 balancers, one of which isn't used at all (the main server's) and one that is. my very silly global_balancers patch fixes that. Yes, making them all global avoids that, but has the nasty side-effect, as mentioned, that balancers defined in one Vhost leak into others... Looking into ways of better handling the inheritance, but anyone have serious comments about committing the patch and working from there? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Apache restriction Outgoing Context
Can any one assit me with were I can find an example filter module, code or website. That will assit me with creating a filter module that filters the context comming from a client machince. I have some users that I provide internet service to and I want to avoid them from sending spam out through my gateway. The way I see this is I will use Apache is a forward proxy and if the user is on the Yahoo email site and sends out spam, I will filter the context before it gets to the Yahoo server and If it contains spam, I will delete the context. I want to set up a restriction sort of like the restriction of access to certain URLs, but instead a rescrition of outgoing context.
Re: Upcoming 2.0.56 release (?)
Colm MacCarthaigh wrote: On Mon, Mar 27, 2006 at 02:26:39AM -0600, William A. Rowe, Jr. wrote: Provided that passes, and if nobody speaks quickly and loudly, I'll RM a tarball once that vote on [EMAIL PROTECTED] flies. Speak now if there are issues :) I don't know if it's implicit or not, but we shouldn't bundle unreleased libraries, so it shouldn't be enough that an apr(-util) passed the vote, it should be GA too. We need thicker chinese walls :) Explain the distinction :) AFAIK APR is holding a vote on releasing 0.9.11. AFAIK APR just held a vote and released 1.2.6. APR hasn't released any alpha/beta versions in a very long time (probably wouldn't either, until they get ready for APR 2.) I've finally deleted that patch proposal which made no sense and taken a look at some more of the proposals. Rather than delete it - you could have also added the subsequent patches that were applied to server/mpm/winnt/mpm_winnt.c. I put in that comment to prod FirstBill to clarify which later patches were necessary. Since this is our first post 2.2 GA release, do we still want feedback from infra? downgrading a.o might send some bad signals ;-) Or maybe there's a subdomain or two running 2.0 still? I think we have alot of sandboxes, but it's true that we aren't quite in shape to eat our own dogfood on 2.0.x anymore. On the other hand, we haven't been running 1.3.x in a very long time, and yet (and rarely) ship a 1.3.x without passing that metric. I doubt we can ever return to that state, but if there are zones running 2.0 it would be nice to get this validated in the real world. On the other hand, it's a sorry state that we can't run anything other than -dev today, I do expect 2.2.1 to be running on our post 2.0 infrastructure before it will garner my +1. Bill
Re: Upcoming 2.0.56 release (?)
On Mon, Mar 27, 2006 at 12:46:05PM -0600, William A. Rowe, Jr. wrote: Provided that passes, and if nobody speaks quickly and loudly, I'll RM a tarball once that vote on [EMAIL PROTECTED] flies. Speak now if there are issues :) I don't know if it's implicit or not, but we shouldn't bundle unreleased libraries, so it shouldn't be enough that an apr(-util) passed the vote, it should be GA too. We need thicker chinese walls :) Explain the distinction :) AFAIK APR is holding a vote on releasing 0.9.11. AFAIK APR just held a vote and released 1.2.6. APR hasn't released any alpha/beta versions in a very long time (probably wouldn't either, until they get ready for APR 2.) Oh I just mean that the tarballs be generally available, ie that apr actually have released. In the past, there have been httpd votes which incorporated an unreleased apr, though it was clear that it would be released by the time httpd was. Now there are some more httpd folk who are not apr folk, and it can be confusing. I've finally deleted that patch proposal which made no sense and taken a look at some more of the proposals. Rather than delete it - you could have also added the subsequent patches that were applied to server/mpm/winnt/mpm_winnt.c. I put in that comment to prod FirstBill to clarify which later patches were necessary. I brought it up on list 3 times, including specifically asking what people meant by the proposal and got nothing, so now it's gone. I couldn't add those patches (it's not even clear what patches were being talked about), as it's not clear that that's what the people voted on. I guess I could have replaced it with a different proposal and reset the vote count to zero. Since this is our first post 2.2 GA release, do we still want feedback from infra? downgrading a.o might send some bad signals ;-) Or maybe there's a subdomain or two running 2.0 still? I think we have alot of sandboxes, but it's true that we aren't quite in shape to eat our own dogfood on 2.0.x anymore. On the other hand, we haven't been running 1.3.x in a very long time, and yet (and rarely) ship a 1.3.x without passing that metric. I doubt we can ever return to that state, but if there are zones running 2.0 it would be nice to get this validated in the real world. On the other hand, it's a sorry state that we can't run anything other than -dev today, I do expect 2.2.1 to be running on our post 2.0 infrastructure before it will garner my +1. +1 -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: AW: Config Bug in proxy_balancer?
On 03/27/2006 05:15 PM, Jim Jagielski wrote:
On Mar 23, 2006, at 9:59 AM, Plüm, Rüdiger, VIS wrote:
-Ursprüngliche Nachricht-
Von: Jim Jagielski
I want to be able to use same balancer in multiple vhosts.
This is actually that way by design, iirc. I've no
real issues with it being Vhost specific or inheritable.
So if others think it's worthwhile having the above
functionality, I'm +1 for it and would work on something
to implement that.
+1 makes sense.
Something like this maybe? Of course, since it's inherited,
the balancer shows up twice in the balancer-manager, but
maybe that make sense :)
Index: modules/proxy/mod_proxy.c
===
--- modules/proxy/mod_proxy.c(revision 389138)
+++ modules/proxy/mod_proxy.c(working copy)
@@ -1625,6 +1625,19 @@
conf = ap_set_config_vectors(cmd-server, new_dir_conf, cmd-path,
proxy_module, cmd-pool);
+if (strncasecmp(cmd-path, balancer:, 9) == 0) {
+proxy_server_conf *sconf =
+ (proxy_server_conf *) ap_get_module_config(cmd-server-
module_config, proxy_module);
+proxy_balancer *balancer = ap_proxy_get_balancer(cmd-pool,
sconf, cmd-path);
+if (!balancer) {
+const char *err = ap_proxy_add_balancer(balancer,
+cmd-pool,
+sconf, cmd-path);
+if (err)
+return apr_pstrcat(cmd-temp_pool, Proxy , err,
NULL);
+}
+}
+
errmsg = ap_walk_config(cmd-directive-first_child, cmd,
new_dir_conf);
if (errmsg != NULL)
return errmsg;
Sorry for being somewhat lost, but currently I struggle to understand what this
patch actually does. So I try to explain what I understood so far. Please
correct
me if I am wrong :-).
If the path of a Proxy block starts with balancer: and this balancer isn't
already
in the server config you add it. The same would happen with todays code provided
that the Proxy block contains at least one BalancerMember directive (an
assumption
which seems to make sense to me).
Currently I do not see how this changes the following configuration problem:
Proxy balancer://fill
BalancerMember http://server1:80 route=server1
BalancerMember http://server2:80 route=server2
/Proxy
VirtualHost *
...
ProxyPass /path balancer://fill/ stickysession=Sticky
/VirtualHost
Because with old and new code a balancer called fill with 2 members gets added
to the
main server config.
The ProxyPass directive in the virtualhost causes another balancer called fill
added
to the (then empty) conf-balancers array of this virtual host configuration.
Afterwards both configurations get merged and we have two balancers called fill
in the merged array conf-balancers for this virtual host: One that is inherited
from the main server with 2 members (and actually is the same balancer as the
one
in the main server) and one empty that got created by ProxyPass inside the
virtual
host. Actually the configuration works because during request processing
ap_proxy_get_balancer starts searching at the beginning of the conf-balancers
array and thus finds the non empty balancer. If I go somewhat further with my
thoughts
and have a look at the following configuration
Proxy balancer://fill
BalancerMember http://server1:80 route=server1
BalancerMember http://server2:80 route=server2
/Proxy
VirtualHost A
...
ProxyPass /path balancer://fill/ stickysession=Sticky
/VirtualHost
VirtualHost B
...
ProxyPass /path balancer://fill/ stickysession=Sticky
/VirtualHost
Then according to my thoughts virtualhost A and B would effectively share the
balancer from the main server. As far as I understood this is a situation
you wanted to avoid.
But as said I am not an expert on these configuration issue, so this maybe
all wrong :-). If yes, please give me a hint where I missed the train.
Regards
Rüdiger
Re: AW: Config Bug in proxy_balancer?
Ruediger Pluem wrote: Proxy balancer://fill BalancerMember http://server1:80 route=server1 BalancerMember http://server2:80 route=server2 /Proxy VirtualHost A ... ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost VirtualHost B ... ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost Then according to my thoughts virtualhost A and B would effectively share the balancer from the main server. As far as I understood this is a situation you wanted to avoid. I want them to share the balancer. Currently, they do not fully. Or have I confused my self... -- Brian Akins Lead Systems Engineer CNN Internet Technologies
Re: AW: Config Bug in proxy_balancer?
On Mar 27, 2006, at 2:55 PM, Ruediger Pluem wrote: Proxy balancer://fill BalancerMember http://server1:80 route=server1 BalancerMember http://server2:80 route=server2 /Proxy VirtualHost A ... ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost VirtualHost B ... ProxyPass /path balancer://fill/ stickysession=Sticky /VirtualHost Then according to my thoughts virtualhost A and B would effectively share the balancer from the main server. As far as I understood this is a situation you wanted to avoid. What we needed to avoid was the case where a balancer defined in VhostA leaked into VhostB. You should not be able to define balancers in one Vhost and have them available in others; it's certainly a weird regression. Now *inheriting* one from the main server does make sense, kindof, and that's what we're trying to do here.
Re: AW: Config Bug in proxy_balancer?
Brian Akins wrote: I want them to share the balancer. Currently, they do not fully. Or have I confused my self... Nah, I understand perfectly :) VHosts should have access to any balancer defined at the main server level. I think we're all in agreement here. The issue is whether vhosts should be allowed to also share and have access to balancers in *other* Vhosts. I don't think they should, that's why making balancers global does make sense. So we need some level of inheritance as well as potentially some level of Vhosts looking at the main server's proxy_conf rec. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: AW: Config Bug in proxy_balancer?
On 03/27/2006 10:03 PM, Jim Jagielski wrote: What we needed to avoid was the case where a balancer defined in VhostA leaked into VhostB. You should not be able to define balancers in one Vhost and have them available in others; it's That makes things clearer to me. Thanks. BTW: I agree with this. certainly a weird regression. Now *inheriting* one from the main server does make sense, kindof, and that's what we're trying to do here. Ok, but this actually works already without your patch. We only face the weird issue right now that an (later) unused empty balancer with the same name gets created in the vhost. Next question: How to deal with parameters set for the balancer via ProxySet? Currently these settings get lost. OTH it wouldn't make sense to apply them to the balancer inherited from the main server if do not create a *complete copy* of this balancer. Ok. Thats enough devils advocate for now :-). Regards Rüdiger
Re: AW: Config Bug in proxy_balancer?
Ruediger Pluem wrote: On 03/27/2006 10:03 PM, Jim Jagielski wrote: What we needed to avoid was the case where a balancer defined in VhostA leaked into VhostB. You should not be able to define balancers in one Vhost and have them available in others; it's That makes things clearer to me. Thanks. BTW: I agree with this. certainly a weird regression. Now *inheriting* one from the main server does make sense, kindof, and that's what we're trying to do here. Ok, but this actually works already without your patch. I never even bothered to check... Brian's initial Email said that it didn't. Are you saying that his Email is wrong and that balancers defined in the main server conf via Proxy, as well as their workers, ARE fully inherited by Vhosts? -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: AW: Config Bug in proxy_balancer?
-Ursprüngliche Nachricht- Von: Jim Jagielski to do here. Ok, but this actually works already without your patch. I never even bothered to check... Brian's initial Email said that it didn't. Are you saying that his Email is wrong and that balancers defined in the main server conf via Proxy, as well as their workers, ARE fully inherited by Vhosts? As far as I saw in my very limited tests: Yes. This does also match with my code analysis I did in one of my previous mails (the one with the 'correct me if I am wrong'). Of course there remain other weird things that are not nice (e.g. the empty balancer created by the VHOST, the fact that the empty balancer is not used because it comes later in the array) Regards Rüdiger
