You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mladen Turk <mt...@apache.org> on 2006/06/26 19:17:51 UTC

Re: svn commit: r417238 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_balancer.xml modules/proxy/mod_proxy_balancer.c

rpluem@apache.org wrote:
> Author: rpluem
> Date: Mon Jun 26 09:59:38 2006
> New Revision: 417238
> 
> +    apr_table_setn(r->subprocess_env,
> +                   "BALANCER_WORKER_ROUTE", (*worker)->s->route);
> +

The worker->s-route is param that can be later tranformed to
the route depending if this is a s->route or s->redirect.
Later I'll add s->standby, so in any case only one
route is ever present and that one you set later
as BALANCER_SESSION_ROUTE.

So, IMO this env var is either duplicate in case the actual
route was chosen or wrong in case of domain clustering.

Regards,
Mladen.

Re: svn commit: r417238 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_balancer.xml modules/proxy/mod_proxy_balancer.c

Posted by Mladen Turk <mt...@apache.org>.
Brian Rectanus wrote:
> 
> RewriteRule "%{ENV:BALANCER_SESSION_ROUTE}

Ahh, of course the env :)
Makes sense.

Regards,
Mladen.

Re: svn commit: r417238 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_balancer.xml modules/proxy/mod_proxy_balancer.c

Posted by Ruediger Pluem <rp...@apache.org>.
Brian Rectanus wrote:

> 
> 
> Yeah, I end up setting on every request.  Some further patching I
> would like to do is add the ability for mod_proxy_balancer to actually
> add/remove the cookie if you use something like
> store-route=cookie:MYCOOKIE or similar.

To be honest I do not like this idea. The first assumption is that the
backend can do what is needed. If it is *not* capable of doing so there
should be a possibility to do this inside httpd (which is currently not
working perfectly with the patch), but this should not cause us to
reinvent the wheel inside mod_proxy_balancer. I am thinking more along
the lines of having SetEnvIf to be able to process things on responses.
I admit that your store-route may be easier to configure, but if we add
the needed conf stuff discussed above to the docs I think it would be as
easy for users to set this up as it is with store-route.

Regards

RĂ¼diger




Re: svn commit: r417238 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_balancer.xml modules/proxy/mod_proxy_balancer.c

Posted by Brian Rectanus <br...@gmail.com>.
Hi,

On 6/27/06, Ruediger Pluem <rp...@apache.org> wrote:
> Brian Rectanus wrote:
> > On 6/26/06, Mladen Turk <mt...@apache.org> wrote:
>
> >>
> >> Thinking of it more deeply, the only valuable env var would
> >> be BALANCER_SESSION_ROUTE.
> >> All other parms are meaningless for the client unless
> >> you wish to create a loadbalancer as a cgi script.
> >>
> >> Regards,
> >> Mladen.
> >>
> >>
> >
> > I had two intentions with BALANCER_SESSION_ROUTE:
> >
> > 1) Provide a way for client to detect a server switch and possibly
> > cleanup (maybe remove the session cookie so next attempt would not
> > fail if server was gone and nofailover=On).  Cleanup will be important
> > since these are session cookies and the server app has no way to
> > cleanup (it is down) and the user must restart his/her browser (remove
> > session cookie) to rebalance.
> >
> > RewriteRule "%{ENV:BALANCER_SESSION_ROUTE}
> > !="%{BALANCER_WORKER_ROUTE}" [E=REBALANCED:1]
> > Header add Set-Cookie "MYCOOKIE=;
> > path=/; expires=Monday, 01-Jan-1990 08:00:00 GMT
> >
> > " env=REBALANCED
>

Doh, yes.  That is what I get for posting examples I have not tested ;)

>
> As far as I can see this also does not work, because these environment
> variables are set during the handler phase and thus are not available
> for rewrite rules.
>
> But I guess the patch can be used to setup the appropriate session
> routing inside of httpd if your backend does not support adding a route
> to the session cookie (this has been requested frequently):
>
> SetEnvIf ^Cookie$  MYCOOKIE HAVE_ROUTE
> Header add Set-Cookie "MYCOOKIE=SOMEVALUE.%{BALANCER_WORKER_ROUTE}e;
> path=/;" env=!HAVE_ROUTE
> ProxyPass /test balancer://mycluster/test stickysession=MYCOOKIE
> nofailover=On
>
>
> Of course this approach does not notice the client once you have
> switched your backend worker. Using
>
>
> Header add Set-Cookie "MYCOOKIE=SOMEVALUE.%{BALANCER_WORKER_ROUTE}e;
> path=/;"
> ProxyPass /test balancer://mycluster/test stickysession=MYCOOKIE
> nofailover=On
>
> fixes this, but sets the cookie on every response which may not be what
> you want.

Yeah, I end up setting on every request.  Some further patching I
would like to do is add the ability for mod_proxy_balancer to actually
add/remove the cookie if you use something like
store-route=cookie:MYCOOKIE or similar.

I'll take a closer look and see if I can get the other env vars to be
a bit more useful.  I ended up adding them in more for completion than
for my needs and as you have seen they are not that useful/practical.

Thanks,
-B

Re: svn commit: r417238 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_balancer.xml modules/proxy/mod_proxy_balancer.c

Posted by Ruediger Pluem <rp...@apache.org>.
Brian Rectanus wrote:
> On 6/26/06, Mladen Turk <mt...@apache.org> wrote:

>>
>> Thinking of it more deeply, the only valuable env var would
>> be BALANCER_SESSION_ROUTE.
>> All other parms are meaningless for the client unless
>> you wish to create a loadbalancer as a cgi script.
>>
>> Regards,
>> Mladen.
>>
>>
> 
> I had two intentions with BALANCER_SESSION_ROUTE:
> 
> 1) Provide a way for client to detect a server switch and possibly
> cleanup (maybe remove the session cookie so next attempt would not
> fail if server was gone and nofailover=On).  Cleanup will be important
> since these are session cookies and the server app has no way to
> cleanup (it is down) and the user must restart his/her browser (remove
> session cookie) to rebalance.
> 
> RewriteRule "%{ENV:BALANCER_SESSION_ROUTE}
> !="%{BALANCER_WORKER_ROUTE}" [E=REBALANCED:1]
> Header add Set-Cookie "MYCOOKIE=;
> path=/; expires=Monday, 01-Jan-1990 08:00:00 GMT
> 
> " env=REBALANCED


As far as I can see this also does not work, because these environment
variables are set during the handler phase and thus are not available
for rewrite rules.

But I guess the patch can be used to setup the appropriate session
routing inside of httpd if your backend does not support adding a route
to the session cookie (this has been requested frequently):

SetEnvIf ^Cookie$  MYCOOKIE HAVE_ROUTE
Header add Set-Cookie "MYCOOKIE=SOMEVALUE.%{BALANCER_WORKER_ROUTE}e;
path=/;" env=!HAVE_ROUTE
ProxyPass /test balancer://mycluster/test stickysession=MYCOOKIE
nofailover=On


Of course this approach does not notice the client once you have
switched your backend worker. Using


Header add Set-Cookie "MYCOOKIE=SOMEVALUE.%{BALANCER_WORKER_ROUTE}e;
path=/;"
ProxyPass /test balancer://mycluster/test stickysession=MYCOOKIE
nofailover=On

fixes this, but sets the cookie on every response which may not be what
you want.

Regards

RĂ¼diger

Re: svn commit: r417238 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_balancer.xml modules/proxy/mod_proxy_balancer.c

Posted by Brian Rectanus <br...@gmail.com>.
On 6/26/06, Mladen Turk <mt...@apache.org> wrote:
> Mladen Turk wrote:
> > rpluem@apache.org wrote:
> >> Author: rpluem
> >> Date: Mon Jun 26 09:59:38 2006
> >> New Revision: 417238
> >>
> >> +    apr_table_setn(r->subprocess_env,
> >> +                   "BALANCER_WORKER_ROUTE", (*worker)->s->route);
> >> +
> >
>
> Thinking of it more deeply, the only valuable env var would
> be BALANCER_SESSION_ROUTE.
> All other parms are meaningless for the client unless
> you wish to create a loadbalancer as a cgi script.
>
> Regards,
> Mladen.
>
>

I had two intentions with BALANCER_SESSION_ROUTE:

1) Provide a way for client to detect a server switch and possibly
cleanup (maybe remove the session cookie so next attempt would not
fail if server was gone and nofailover=On).  Cleanup will be important
since these are session cookies and the server app has no way to
cleanup (it is down) and the user must restart his/her browser (remove
session cookie) to rebalance.

RewriteRule "%{ENV:BALANCER_SESSION_ROUTE}
!="%{BALANCER_WORKER_ROUTE}" [E=REBALANCED:1]
Header add Set-Cookie "MYCOOKIE=;
path=/; expires=Monday, 01-Jan-1990 08:00:00 GMT

" env=REBALANCED

2) Provide a way to get the value of session route w/o parsing
URL/header for the parameter/cookie value.

RewriteRule "%{ENV:BALANCER_SESSION_ROUTE}
!="%{BALANCER_WORKER_ROUTE}" [E=REBALANCED:1]
Header set X-OldSession "%{ENV:BALANCER_SESSION_ROUTE}"

But, looking at 2 again, it will not work anyway since it is not added
to env until later in cycle.  I'll look at that more.


BALANCER_SESSION_STICKY was to allow the client to be able to pass the
cookie name on to the server dynamically or use the value to parse the
url/cookie header for the value.  It is also used as a note in
mod_proxy_balancer.c, so I thought since it was important enough for
that it might be useful in the environment as well ;)

SetEnvIf ^Cookie$ "${BALANCER_SESSION_STICKY}=([^ \.;]*)\.([^ ;]*)" MYROUTE=$1

But, as 2 above fails, so does this.


BALANCER_WORKER_NAME was intended to be used by output filters such as
mod_proxy_html, etc.  But, it also adds a unique identifier when no
route= parameter is used.  BALANCER_NAME is to make
BALANCER_WORKER_NAME unique if multiple balancers are used in a given
context.  So "%{BALANCER_NAME}e%{BALANCER_WORKER_NAME}" is a unique
identifier to where the request is routed when there is no route=
parameter used.


Thanks,
-B

Re: svn commit: r417238 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_proxy_balancer.xml modules/proxy/mod_proxy_balancer.c

Posted by Mladen Turk <mt...@apache.org>.
Mladen Turk wrote:
> rpluem@apache.org wrote:
>> Author: rpluem
>> Date: Mon Jun 26 09:59:38 2006
>> New Revision: 417238
>>
>> +    apr_table_setn(r->subprocess_env,
>> +                   "BALANCER_WORKER_ROUTE", (*worker)->s->route);
>> +
> 

Thinking of it more deeply, the only valuable env var would
be BALANCER_SESSION_ROUTE.
All other parms are meaningless for the client unless
you wish to create a loadbalancer as a cgi script.

Regards,
Mladen.