You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Georg von Zezschwitz <gv...@garnix.de> on 2007/04/02 13:50:47 UTC
Bug 41897 / Session-Stickiness with mod_proxy_balancer
Hi,
As I (with Rüdigers help :-) ) found out, there is already a bug report
to my problem:
#41897 describes the problem that the case-sensitivity of the
"stickysession"-Parameter
does not comply to the Java Servlet Spec (Cookie: "JSESSIONID", url
based session
management ";jsessionid").
To solve this problem in a backward compatible way, I'd like to suggest
the following
solution before writing a patch:
Add two parameters "stickysessionpath" and "stickysessioncookie".
"stickysessionpath" sets the session name for URL based session
management and might
be something like ";jsessionid". "stickysessioncookie" sets the session
name for Cookie based
session management.
"stickysession" should set the session name for both parameters.
Pro:
- It does solve the problem
- One can explicitly choose to use *only* one of the two algorithms.
- Currently, only the sequence "<session name>=" is searched. However,
in Java
environments, a ";jsessionid=" would be more precise...
An alternative would be to have an option to search the session name
case-insensitive.
Could I get "votes" if my approach / an according patch is acceptable?
Best regards,
Georg
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mathias Herberts <ma...@gmail.com>.
The message I posted earlier (in march) contains a patch to address this issue.
Mathias.
On 4/2/07, Georg von Zezschwitz <gv...@garnix.de> wrote:
> Hi,
>
> As I (with Rüdigers help :-) ) found out, there is already a bug report
> to my problem:
> #41897 describes the problem that the case-sensitivity of the
> "stickysession"-Parameter
> does not comply to the Java Servlet Spec (Cookie: "JSESSIONID", url
> based session
> management ";jsessionid").
>
> To solve this problem in a backward compatible way, I'd like to suggest
> the following
> solution before writing a patch:
>
> Add two parameters "stickysessionpath" and "stickysessioncookie".
> "stickysessionpath" sets the session name for URL based session
> management and might
> be something like ";jsessionid". "stickysessioncookie" sets the session
> name for Cookie based
> session management.
>
> "stickysession" should set the session name for both parameters.
>
> Pro:
> - It does solve the problem
> - One can explicitly choose to use *only* one of the two algorithms.
> - Currently, only the sequence "<session name>=" is searched. However,
> in Java
> environments, a ";jsessionid=" would be more precise...
>
> An alternative would be to have an option to search the session name
> case-insensitive.
>
> Could I get "votes" if my approach / an according patch is acceptable?
>
> Best regards,
>
>
>
> Georg
>
>
>
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Georg von Zezschwitz <gv...@2scale.de>.
Mladen Turk wrote:
> ...
> or perhaps a different notation ...
> stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION
I like that much more - these "flags" like "[C]" rather raise questions
like
"can I add multiple of them?".
What about this?:
"stickysession"
The attribute can occur multiple times within a Balancer directive.
The session identifier is searched in the sequence of the occurrence of
these attributes.
Each value modifier can be preceded by one of the modifiers
"(Cookie|Path|Env)" followed by a colon,
meaning that the identifier is only searched as a Cookie, an URL path
element or in
the environment.
Without a modifier, the identifier will be searched in both the path and
the cookie. (backward compatibility).
The search for the identifier is case-sensitive.
Regards,
Georg
AW: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Georg von Zezschwitz
> Gesendet: Dienstag, 8. Mai 2007 10:05
> An: dev@httpd.apache.org
> Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
>
> You declare a balancer:
>
> <Proxy balancer://mycloud>
> BalancerMember ajp://192.168.1.1:5001 route=member1
> BalancerMember ajp://192.168.1.2:5001 route=member2
> </Proxy>
>
> Now I want to balance 2 paths:
>
> <Location /app1>
> ProxyPass balancer://mycloud/app1 stickysession=JSESSION
> </Location>
>
> <Location /app2>
> ProxyPass balancer://mycloud/app2 stickysession=JSESSION
> </Location>
>
> The repeated ProxyPass definitions might give the impression that you
> can specify
> different settings for /app1 and /app2 - e.g. stickysession
> parameters
> (which is not true).
>
> Using an elegant:
>
> <LocationMatch "/(app1|app2)">
>
> is also not possible if the path element (/app1 vs /app2) has to be
> passed to the backend.
What about this?
RewriteRule ^/(app1|app2)(.*) balancer://mycloud/$1$2 [P]
<Proxy balancer://mycloud>
BalancerMember ajp://192.168.1.1:5001 route=member1
BalancerMember ajp://192.168.1.2:5001 route=member2
ProxySet stickysession=JSESSION
</Proxy>
Hint: You may need to apply the following patch from trunk to get this working:
http://svn.apache.org/viewvc?view=rev&revision=427920
Regards
Rüdiger
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Georg von Zezschwitz <gv...@2scale.de>.
Ruediger Pluem wrote:
> - for (i = 0; i < arr->nelts; i++) {
> - const char *err = set_balancer_param(conf, cmd->pool, balancer, elts[i].key,
> - elts[i].val);
> + else {
> + if (params->nelts > 0 &&
> + (balancer->sticky || balancer->sticky_force ||
> + balancer->max_attempts_set || balancer->timeout)) {
> + ap_log_error(APLOG_MARK, APLOG_WARNING, 0, cmd->server,
> + "repeated parameter definition for balancer %s "
> + "overwrites previous definitions",
> + balancer->name);
> + balancer->sticky = NULL;
>
> Why resetting balancer->sticky here? It is not clear that the contents of
> balancer->sticky is changed. It makes sense to reset it if we have at least
> one "stickysession" parameter inside of params->elts so that we cleanly
> overwrite all the "stickysession" stuff then.
>
What makes me a bit lost is the following configuration situation:
You declare a balancer:
<Proxy balancer://mycloud>
BalancerMember ajp://192.168.1.1:5001 route=member1
BalancerMember ajp://192.168.1.2:5001 route=member2
</Proxy>
Now I want to balance 2 paths:
<Location /app1>
ProxyPass balancer://mycloud/app1 stickysession=JSESSION
</Location>
<Location /app2>
ProxyPass balancer://mycloud/app2 stickysession=JSESSION
</Location>
The repeated ProxyPass definitions might give the impression that you
can specify
different settings for /app1 and /app2 - e.g. stickysession parameters
(which is not true).
Using an elegant:
<LocationMatch "/(app1|app2)">
is also not possible if the path element (/app1 vs /app2) has to be
passed to the backend.
I am missing an elegant solution for mapping multiple paths to the same
balancer.
Did I miss something here?
Best regards,
Georg
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jean-Frederic <jf...@gmail.com>.
On Mon, 2007-05-07 at 21:05 +0200, Ruediger Pluem wrote:
>
> On 05/07/2007 05:56 PM, Mladen Turk wrote:
>
> >
> > I think we could use a simple two use case situation.
> > To be able to backport that to the 2.2 branch I propose
> > a following patch.
> >
> > It adds additional struct member sticky_path that is
> > set to the sticky so if someone has in the config
> >
> > ... stickysession=JSESSIONID ... both sticky and
> > sticky_path will be the same.
> > However if there is a stickysession with
> > ... stickysession=JSESSIONID|;jsessionid ...
> > will make w->sticky=JSESSIONID and w->sticky_path=;jsessionid
> >
> > I'm not aware of any other way without introducing additional
> > directives that could be backported to 2.2
> >
> > The question is, is that backportable as well?
>
> I think this is backportable in general if we do a minor bump (which
> is possible for backports). Currently I see the following problems
> with the patch which seem to be solvable:
>
> 1. Documentation.
> We definitely need a patch for the documentation that describes how
> to handle the servlet case with the above patch. Otherwise people keep
> falling into the pit.
>
> 2. Apart from route search balancer->sticky is used in several additional
> locations for
>
> - Status pages (mod_status hook, loadbalancer manager)
> - Some notes / environment variables are set to balancer->sticky which is
> wrong if balancer->sticky_path was used to find the actual route.
> Furthermore it might be worth adding an additional environment variable
> (e.g. BALANCER_SESSION_STICKY_TYPE) that indicates whether
> BALANCER_SESSION_STICKY contains balancer->sticky or balancer->sticky_path.
>
> Adjusting sessionstickyness via the loadbalancer manager might not be needed as this
> currently does not work anyway since the balancer configuration is not stored in shared
> memory (Maybe we should turn off the possibility to change the balancer configuration via
> the manager until this is fixed as this can lead to weird results with different
> processes using different configurations).
Yes we should avoid adjust sessionstickyness via the loadbalancer
manager because it won't work with prefork and worker mpm.
>
> 3. The minor bump is missing which is needed due to the change of the struct.
>
> 4. I am confused by the following part of the patch :-):
>
> + balancer->sticky = balancer->sticky_path = apr_pstrdup(p, val);
> + if ((path = strchr(balancer->sticky, '|'))) {
> + *path++ = '\0';
> + balancer->sticky_path = path;
> + }
> + else
> + balancer->sticky_path = balancer->sticky;
>
> Why setting balancer->sticky_path twice in both cases (string with or without |)
Right no need of the else here.
Cheers
Jean-Frederic
>
>
> Regards
>
> Rüdiger
>
>
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Ruediger Pluem <rp...@apache.org>.
On 05/07/2007 05:56 PM, Mladen Turk wrote:
>
> I think we could use a simple two use case situation.
> To be able to backport that to the 2.2 branch I propose
> a following patch.
>
> It adds additional struct member sticky_path that is
> set to the sticky so if someone has in the config
>
> ... stickysession=JSESSIONID ... both sticky and
> sticky_path will be the same.
> However if there is a stickysession with
> ... stickysession=JSESSIONID|;jsessionid ...
> will make w->sticky=JSESSIONID and w->sticky_path=;jsessionid
>
> I'm not aware of any other way without introducing additional
> directives that could be backported to 2.2
>
> The question is, is that backportable as well?
I think this is backportable in general if we do a minor bump (which
is possible for backports). Currently I see the following problems
with the patch which seem to be solvable:
1. Documentation.
We definitely need a patch for the documentation that describes how
to handle the servlet case with the above patch. Otherwise people keep
falling into the pit.
2. Apart from route search balancer->sticky is used in several additional
locations for
- Status pages (mod_status hook, loadbalancer manager)
- Some notes / environment variables are set to balancer->sticky which is
wrong if balancer->sticky_path was used to find the actual route.
Furthermore it might be worth adding an additional environment variable
(e.g. BALANCER_SESSION_STICKY_TYPE) that indicates whether
BALANCER_SESSION_STICKY contains balancer->sticky or balancer->sticky_path.
Adjusting sessionstickyness via the loadbalancer manager might not be needed as this
currently does not work anyway since the balancer configuration is not stored in shared
memory (Maybe we should turn off the possibility to change the balancer configuration via
the manager until this is fixed as this can lead to weird results with different
processes using different configurations).
3. The minor bump is missing which is needed due to the change of the struct.
4. I am confused by the following part of the patch :-):
+ balancer->sticky = balancer->sticky_path = apr_pstrdup(p, val);
+ if ((path = strchr(balancer->sticky, '|'))) {
+ *path++ = '\0';
+ balancer->sticky_path = path;
+ }
+ else
+ balancer->sticky_path = balancer->sticky;
Why setting balancer->sticky_path twice in both cases (string with or without |)
Regards
Rüdiger
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mladen Turk <mt...@apache.org>.
Ruediger Pluem wrote:
>
> On 04/06/2007 01:13 PM, Georg von Zezschwitz wrote:
>> Jim Jagielski wrote:
>>
>>
>> attached is the patch for trunk with documentation & Co.
>>
>> Could anybody review it & commit?
>
> Many thanks for sending the patch and my apologies that reviewing it took
> that long. Please find my comments below.
>
I think we could use a simple two use case situation.
To be able to backport that to the 2.2 branch I propose
a following patch.
It adds additional struct member sticky_path that is
set to the sticky so if someone has in the config
... stickysession=JSESSIONID ... both sticky and
sticky_path will be the same.
However if there is a stickysession with
... stickysession=JSESSIONID|;jsessionid ...
will make w->sticky=JSESSIONID and w->sticky_path=;jsessionid
I'm not aware of any other way without introducing additional
directives that could be backported to 2.2
The question is, is that backportable as well?
If it is, I'll put that for a vote in STATUS.
Regards,
Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/06/2007 01:13 PM, Georg von Zezschwitz wrote:
> Jim Jagielski wrote:
>
>>>
>>> If we state that the evaluation takes place in the occurence of
>>> stickysession attributes
>>> and suggest
>>>
>>> stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid to
>>> the user
>>>
>>> it will perform faster in average.
>>>
>>> As I promised to write the patch, I would do it the way Jim suggested
>>> it for backward
>>> compatibility, however I would also add a table "sticky_type"
>>> containing the "Cookie vs.
>>> Path vs. Env"-prefix (in a parsed way) to the balancer struct.
>>>
>>> Is this OK for everybody?
>>>
>>
>> Patch for trunk...
>
>
> Hi,
>
> attached is the patch for trunk with documentation & Co.
>
> Could anybody review it & commit?
Many thanks for sending the patch and my apologies that reviewing it took
that long. Please find my comments below.
Regards
Rüdiger
Throughout the code there are a number of code style issues that should
be fixed. Most of them are related to missing spaces before or after
assignments or operators. I do not mention them explicitly in my review
later. Please have a look at http://httpd.apache.org/dev/styleguide.html.
Index: docs/manual/mod/mod_proxy.xml
===================================================================
--- docs/manual/mod/mod_proxy.xml (revision 526077)
+++ docs/manual/mod/mod_proxy.xml (working copy)
@@ -707,9 +707,19 @@
</td></tr>
<tr><td>stickysession</td>
<td>-</td>
- <td>Balancer sticky session name. The value is usually set to something
- like <code>JSESSIONID</code> or <code>PHPSESSIONID</code>,
- and it depends on the backend application server that support sessions.
+ <td>Balancer sticky session name. Multiple definitions are possible and
+ are interpreted in the sequence of their definition. The
+ value can be preceeded with a specification <code>Cookie</code>,
+ <code>Path</code> or <code>Env</code> to restrict the search.
+ Without this specification, the identifier is searched in the URL path
+ and then in the cookie. The value is usually set to something
+ like <code>JSESSIONID</code> or <code>PHPSESSIONID</code>, e.g.
+ <br/><indent>
+ <code>stickysession=Cookie:JSESSIONID
+ stickysession=Path:;jsessionid</code>
+ </indent>
+ for Java Servlets and depends on the backend application server
+ that support sessions.
I think the examples should be split into two separate sentences: One for the
simple case (no specification) for which PHPSESSIONID is a good example and
one for the more complex case (two settings with different specifications) for
which Java Servlets are a good example.
Index: modules/proxy/mod_proxy_balancer.c
===================================================================
--- modules/proxy/mod_proxy_balancer.c (revision 526077)
+++ modules/proxy/mod_proxy_balancer.c (working copy)
@@ -581,6 +605,30 @@
}
}
+static void print_balancer_sticky(request_rec *r,
+ apr_array_header_t *sticky)
+{
+ int i;
+ struct proxy_sticky_entry *entries;
+
+ if (sticky==NULL)
+ return;
+ entries = (struct proxy_sticky_entry *) sticky->elts;
+ for (i = 0; i < sticky->nelts; i++) {
+ if (i>0)
+ ap_rputs (" ", r);
+ switch (entries[i].method) {
+ case PROXY_STICKY_COOKIE:
+ ap_rputs ("Cookie:", r); break;
+ case PROXY_STICKY_PATH:
+ ap_rputs ("Path:", r); break;
+ case PROXY_STICKY_ENV:
+ ap_rputs ("Env:", r); break;
Style
+ }
+ ap_rputs (entries[i].name, r);
+ }
+}
+
/* Manages the loadfactors and member status
*/
static int balancer_handler(request_rec *r)
@@ -645,10 +693,30 @@
if (bsel) {
const char *val;
if ((val = apr_table_get(params, "ss"))) {
- if (strlen(val))
- bsel->sticky = apr_pstrdup(conf->pool, val);
- else
- bsel->sticky = NULL;
+ char *tok_cntx;
+ bsel->sticky = apr_array_make(conf->pool, 1,
+ sizeof (struct proxy_sticky_entry));
+ char *v = apr_strtok(apr_pstrdup(r->pool, val), "+", &tok_cntx);
This is not allowed in ANSI C: Declarations of variables need to be at the
beginning of a block. Better use ap_strchr here.
+ while (v!=NULL) {
+ struct proxy_sticky_entry * entry =
+ (struct proxy_sticky_entry *) apr_array_push(bsel->sticky);
+ const char *colon_pos = strchr (v, ':');
+ entry->method = PROXY_STICKY_COOKIE | PROXY_STICKY_PATH;
+ if (colon_pos!=NULL) {
+ while (*++colon_pos==' ')
+ continue;
+ entry->name = apr_pstrdup(conf->pool, colon_pos);
+ if (!strncasecmp ("cookie:", v, 7))
+ entry->method = PROXY_STICKY_COOKIE;
+ else if (!strncasecmp ("path:", v, 5))
+ entry->method = PROXY_STICKY_PATH;
+ else if (!strncasecmp ("env:", v, 4))
+ entry->method = PROXY_STICKY_ENV;
+ } else {
+ entry->name = apr_pstrdup(conf->pool, v);
+ }
+ v = apr_strtok(NULL, "+", &tok_cntx);
+ }
}
if ((val = apr_table_get(params, "tm"))) {
int ival = atoi(val);
Index: modules/proxy/mod_proxy.c
===================================================================
--- modules/proxy/mod_proxy.c (revision 526077)
+++ modules/proxy/mod_proxy.c (working copy)
@@ -272,14 +272,36 @@
const char *key,
const char *val)
{
-
int ival;
if (!strcasecmp(key, "stickysession")) {
- /* Balancer sticky session name.
- * Set to something like JSESSIONID or
- * PHPSESSIONID, etc..,
- */
- balancer->sticky = apr_pstrdup(p, val);
+ /* Balancer sticky session name.
+ * Set to something like JSESSIONID or
+ * PHPSESSIONID, etc..,
+ */
+ struct proxy_sticky_entry *entry;
+
+ if (balancer->sticky==NULL)
+ balancer->sticky =
+ apr_array_make(p, 1, sizeof (struct proxy_sticky_entry));
+ entry = (struct proxy_sticky_entry *) apr_array_push(balancer->sticky);
+ const char *colon_pos = strchr (val, ':');
This is not allowed in ANSI C: Declarations of variables need to be at the
beginning of a block. Better use ap_strchr_c here.
+ if (colon_pos!=NULL) {
+ while (*++colon_pos==' ')
+ continue;
+ entry->name = apr_pstrdup(p, colon_pos);
+ if (!strncasecmp ("cookie:", val, 7))
+ entry->method = PROXY_STICKY_COOKIE;
+ else if (!strncasecmp ("path:", val, 5))
+ entry->method = PROXY_STICKY_PATH;
+ else if (!strncasecmp ("env:", val, 4))
+ entry->method = PROXY_STICKY_ENV;
+ else
+ return "stickysession must be preceeded by Cookie|Path|Env "
+ "followed by a colon";
+ } else {
+ entry->method = PROXY_STICKY_COOKIE | PROXY_STICKY_PATH;
+ entry->name = apr_pstrdup(p, val);
+ }
This looks very similar to the logic in mod_proxy_balancer.c. Does it make
sense to duplicate the code? Shouldn't this be moved to proxy_util.c?
@@ -324,7 +346,7 @@
return "unknown lbmethod";
}
else {
- return "unknown Balancer parameter";
+ return apr_pstrcat (p, "unknown Balancer parameter ", key);
The last parameter to apr_pstrcat needs to be NULL.
}
return NULL;
}
@@ -1152,7 +1173,8 @@
}
else
*val++ = '\0';
- apr_table_setn(params, word, val);
>From my personal point of view I would prefer staying with the table and
just do apr_table_addn when it comes to stickysession to have this key in
the table multiple times.
+ * (const char**) (apr_array_push (params)) = word;
+ * (const char**) (apr_array_push (params)) = val;
This style looks nasty and may break on some compilers. Please use a temporary
variable to save the return value of apr_array_push.
}
};
@@ -1177,9 +1198,20 @@
if (err)
return apr_pstrcat(cmd->temp_pool, "ProxyPass ", err, NULL);
}
- for (i = 0; i < arr->nelts; i++) {
- const char *err = set_balancer_param(conf, cmd->pool, balancer, elts[i].key,
- elts[i].val);
+ else {
+ if (params->nelts > 0 &&
+ (balancer->sticky || balancer->sticky_force ||
+ balancer->max_attempts_set || balancer->timeout)) {
+ ap_log_error(APLOG_MARK, APLOG_WARNING, 0, cmd->server,
+ "repeated parameter definition for balancer %s "
+ "overwrites previous definitions",
+ balancer->name);
+ balancer->sticky = NULL;
Why resetting balancer->sticky here? It is not clear that the contents of
balancer->sticky is changed. It makes sense to reset it if we have at least
one "stickysession" parameter inside of params->elts so that we cleanly
overwrite all the "stickysession" stuff then.
Index: modules/proxy/mod_proxy.h
===================================================================
--- modules/proxy/mod_proxy.h (revision 526077)
+++ modules/proxy/mod_proxy.h (working copy)
@@ -373,6 +373,15 @@
void *context; /* general purpose storage */
};
+struct proxy_sticky_entry {
+ const char *name; /* key to look for, e.g. JSESSIONID */
+ int method; /* where to search, e.g. PROXY_STICKY_ENV */
+};
I would add a typedef for this struct like for the other structs here.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Georg von Zezschwitz <gv...@2scale.de>.
Jim Jagielski wrote:
>>
>> If we state that the evaluation takes place in the occurence of
>> stickysession attributes
>> and suggest
>>
>> stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid to
>> the user
>>
>> it will perform faster in average.
>>
>> As I promised to write the patch, I would do it the way Jim suggested
>> it for backward
>> compatibility, however I would also add a table "sticky_type"
>> containing the "Cookie vs.
>> Path vs. Env"-prefix (in a parsed way) to the balancer struct.
>>
>> Is this OK for everybody?
>>
>
> Patch for trunk...
Hi,
attached is the patch for trunk with documentation & Co.
Could anybody review it & commit?
Cheers,
Georg
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 4, 2007, at 11:34 AM, Georg von Zezschwitz wrote:
> Jim Jagielski schrieb:
>> Rüdiger's point is that we would be doing the "scanning"
>> for each and every request, which is wasteful since they
>> aren't changing. Even in the above the strlen() is
>> counting chars that don't change between requests.
>
> the performance aspect is why I would also prefer the "arbitrary
> sequence of stickysession-attributes"
> with an optional Cookie/Path-prefix.
>
> Currently, the URL path search is performed before the Cookie search.
> I do not know why this sequence was chosen (most users will rather
> support cookie-based
> session management, so the URL approach is less likely to match).
> If we state that the evaluation takes place in the occurence of
> stickysession attributes
> and suggest
>
> stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid
> to the user
>
> it will perform faster in average.
>
> As I promised to write the patch, I would do it the way Jim
> suggested it for backward
> compatibility, however I would also add a table "sticky_type"
> containing the "Cookie vs.
> Path vs. Env"-prefix (in a parsed way) to the balancer struct.
>
> Is this OK for everybody?
>
Patch for trunk...
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Georg von Zezschwitz <gv...@2scale.de>.
Jim Jagielski schrieb:
> Rüdiger's point is that we would be doing the "scanning"
> for each and every request, which is wasteful since they
> aren't changing. Even in the above the strlen() is
> counting chars that don't change between requests.
the performance aspect is why I would also prefer the "arbitrary
sequence of stickysession-attributes"
with an optional Cookie/Path-prefix.
Currently, the URL path search is performed before the Cookie search.
I do not know why this sequence was chosen (most users will rather
support cookie-based
session management, so the URL approach is less likely to match).
If we state that the evaluation takes place in the occurence of
stickysession attributes
and suggest
stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid to
the user
it will perform faster in average.
As I promised to write the patch, I would do it the way Jim suggested it
for backward
compatibility, however I would also add a table "sticky_type" containing
the "Cookie vs.
Path vs. Env"-prefix (in a parsed way) to the balancer struct.
Is this OK for everybody?
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 4, 2007, at 10:42 AM, Mladen Turk wrote:
> Plüm wrote:
>> Plus does it make sense to split the sticky string everytime we
>> search
>> for a route? From my performance feeling this split should be done
>> during
>> configuration time.
>
> We can use the NUL separated double NUL terminated string.
> Then a part is start + strlen(start)
>
Rüdiger's point is that we would be doing the "scanning"
for each and every request, which is wasteful since they
aren't changing. Even in the above the strlen() is
counting chars that don't change between requests.
Oh yeah, I think that having sticky set to the 1st
non-null entry would be better, as far as expected behavior.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mladen Turk <mt...@apache.org>.
Plüm wrote:
>
>
> Plus does it make sense to split the sticky string everytime we search
> for a route? From my performance feeling this split should be done during
> configuration time.
We can use the NUL separated double NUL terminated string.
Then a part is start + strlen(start)
Regards,
Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 4, 2007, at 10:27 AM, Plüm, Rüdiger, VF-Group wrote:
>>
>> Hmmm... I like this idea. Not sure about the use of '/'
>> as the delim (simply because of its "other" meanings) but
>> that's secondary.
>>
>> Of course, we can't use strtok, since sticky is a const
>> char and we can't be shoving NULLs in there :)
>
> Plus does it make sense to split the sticky string everytime we search
> for a route? From my performance feeling this split should be done
> during
> configuration time.
Agreed... It doesn't change.
> How about adding either a const char * some_name[FIXED_VALUE] or an
> apr_array_header_t * to the end of struct proxy_balancer to store
> the results
> of the split and setting sticky = some_name[last_non_null_entry]
> for backward
> compatibility?
>
We already have an existing context we could overload
or simply append another element to the struct.
Of course, doing that really confuses the whole issue, since
we're doing all these weird things to get around changing
sticky from a const char* to a apr_array_header_t*...
Sooo... how about in trunk making it right (sticky ->
apr_array_header_t*)
and in 2.2 appending sticky_table (apr_array_header_t*)...
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski
> Gesendet: Mittwoch, 4. April 2007 16:16
> An: dev@httpd.apache.org
> Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
>
>
>
> On Apr 4, 2007, at 9:38 AM, Mladen Turk wrote:
>
> > Plüm wrote:
> >>>>
> >>> Yes, although MAX_ENTRIES would be 3 for now
> >>> (cookie, path and env)
> >> But this means that we break the ABI here. If struct
> >> proxy_balancer is part
> >> of a public API (I am not sure about this) this would require a
> >> major bump
> >> and would prevent backporting.
> >>
> >
> > The other solution is to keep that in balancer->sticky
> > separated by / (think %2f is unacceptable char anyhow)
> > and do a strtok inside find_session_route.
> >
>
> Hmmm... I like this idea. Not sure about the use of '/'
> as the delim (simply because of its "other" meanings) but
> that's secondary.
>
> Of course, we can't use strtok, since sticky is a const
> char and we can't be shoving NULLs in there :)
Plus does it make sense to split the sticky string everytime we search
for a route? From my performance feeling this split should be done during
configuration time.
How about adding either a const char * some_name[FIXED_VALUE] or an
apr_array_header_t * to the end of struct proxy_balancer to store the results
of the split and setting sticky = some_name[last_non_null_entry] for backward
compatibility?
Regards
Rüdiger
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 4, 2007, at 9:38 AM, Mladen Turk wrote:
> Plüm wrote:
>>>>
>>> Yes, although MAX_ENTRIES would be 3 for now
>>> (cookie, path and env)
>> But this means that we break the ABI here. If struct
>> proxy_balancer is part
>> of a public API (I am not sure about this) this would require a
>> major bump
>> and would prevent backporting.
>>
>
> The other solution is to keep that in balancer->sticky
> separated by / (think %2f is unacceptable char anyhow)
> and do a strtok inside find_session_route.
>
Hmmm... I like this idea. Not sure about the use of '/'
as the delim (simply because of its "other" meanings) but
that's secondary.
Of course, we can't use strtok, since sticky is a const
char and we can't be shoving NULLs in there :)
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mladen Turk <mt...@apache.org>.
Plüm wrote:
>>>
>> Yes, although MAX_ENTRIES would be 3 for now
>> (cookie, path and env)
>
> But this means that we break the ABI here. If struct proxy_balancer is part
> of a public API (I am not sure about this) this would require a major bump
> and would prevent backporting.
>
The other solution is to keep that in balancer->sticky
separated by / (think %2f is unacceptable char anyhow)
and do a strtok inside find_session_route.
That way one could have N session cookie/path identifiers.
so:
stickysession=JSESSIONID/;jsessionid
or:
stickysession=JSESSIONID stickysession=;jsessionid
would have in balancer->sticky="JSESSIONID/;jsessionid"
inside find_session route do a strtok and iterate
until null or cookie|path found.
>
> But r->subprocess_env is a table and apr_table_get is never case sensitive.
The case sensitivity was just an idea as well as env.
If you guys think it's not needed fine with me.
Regards,
Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 4, 2007, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote:
>
> But this means that we break the ABI here. If struct proxy_balancer
> is part
> of a public API (I am not sure about this) this would require a
> major bump
> and would prevent backporting.
Since the whole idea of loadable lb method via providers
implies an external API to do this, I consider it a public API.
>
> But r->subprocess_env is a table and apr_table_get is never case
> sensitive.
> So the case parameter does not make sense for environment variables.
> To be honest I do not understand why we need the case parameter at
> all (also
> for cookie and path). I did not understand the hint you gave
> regarding PHP
> and ASP on Jean-Frederic's question on the same matter.
>
FWIW, neither did I.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
Thanks for the clarifications.
> -----Ursprüngliche Nachricht-----
> Von: Mladen Turk
> Gesendet: Mittwoch, 4. April 2007 13:36
> An: dev@httpd.apache.org
> Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
>
>
> Plüm wrote:
> >
> >
> > 1. You want to change sticky in struct proxy_balancer from
> > const char *sticky
> >
> > to something like
> >
> > const char *sticky[MAX_ENTRIES]
> >
>
> Yes, although MAX_ENTRIES would be 3 for now
> (cookie, path and env)
But this means that we break the ABI here. If struct proxy_balancer is part
of a public API (I am not sure about this) this would require a major bump
and would prevent backporting.
>
> >
> > Why is FOO stored in balancer->sticky-[2]? Is it because
> stickysession="FOO"
> > is the 3rd occurrence of stickysession for this worker
> or is it because of
> > the name "FOO"?
> >
>
> Because it's a third occurrence. This is to keep the
> compatibility with
> current configurations users may have.
> In case one is not present it will be skipped during the
> find_session_route.
>
> > 7. What is the purpose of [E] [e]? Where will you search
> for balancer->sticky[2]?
> > In r->subprocess_env?
> >
>
> Needs to be added. (a simple check for r->subprocess_env)
But r->subprocess_env is a table and apr_table_get is never case sensitive.
So the case parameter does not make sense for environment variables.
To be honest I do not understand why we need the case parameter at all (also
for cookie and path). I did not understand the hint you gave regarding PHP
and ASP on Jean-Frederic's question on the same matter.
Regards
Rüdiger
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mladen Turk <mt...@apache.org>.
Plüm wrote:
>
>
> 1. You want to change sticky in struct proxy_balancer from
> const char *sticky
>
> to something like
>
> const char *sticky[MAX_ENTRIES]
>
Yes, although MAX_ENTRIES would be 3 for now
(cookie, path and env)
>
> Why is FOO stored in balancer->sticky-[2]? Is it because stickysession="FOO"
> is the 3rd occurrence of stickysession for this worker or is it because of
> the name "FOO"?
>
Because it's a third occurrence. This is to keep the compatibility with
current configurations users may have.
In case one is not present it will be skipped during the find_session_route.
> 7. What is the purpose of [E] [e]? Where will you search for balancer->sticky[2]?
> In r->subprocess_env?
>
Needs to be added. (a simple check for r->subprocess_env)
Regards,
Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Mladen Turk
> Gesendet: Dienstag, 3. April 2007 17:25
> An: dev@httpd.apache.org
> Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
>
>
> stickysession=JSESSIONID stickysession=;jsessionid
> stickysession=MYSESSION
>
> would mean:
> balancer->sticky[0]=JSESSIONID
> balancer->sticky[1]=;jsessionid
> balancer->sticky[2]=MYSESSION
>
> balancer->sticky_case[0]=1
> balancer->sticky_case[1]=1
> balancer->sticky_case[2]=1
>
> OTOH
> stickysession="JSESSIONID [c]" stickysession="MYSESSION [E]"
> or perhaps a different notation ...
> stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION
>
>
> would mean:
> balancer->sticky[0]=JSESSIONID
> balancer->sticky[1]=NULL
> balancer->sticky[2]=MYSESSION
>
> balancer->sticky_case[0]=0
> balancer->sticky_case[1]=-1
> balancer->sticky_case[2]=1
Hm. I am not quite sure if I get your idea right now. So this is what
I understand:
1. You want to change sticky in struct proxy_balancer from
const char *sticky
to something like
const char *sticky[MAX_ENTRIES]
Additionally you want to add something like
int sticky_case[MAX_ENTRIES]
to struct proxy_balancer, right?
2. If balancer->sticky_case[ ] == 1 you want to do a case sensitive search
whereas if balancer->sticky_case[ ] == 0 you want to do a case insensitive
search.
3. stickysession settings with [C] or [c] are always put in balancer->sticky[0]
stickysession settings with [P] or [p] are always put in balancer->sticky[1]
stickysession settings with [E] or [e] are always put in balancer->sticky[2]
I does not matter in which order you configure this. So
stickysession="JSESSIONID [c]" stickysession="MYSESSION [E]" and
stickysession="MYSESSION [E]" stickysession="JSESSIONID [c]"
both would result in
balancer->sticky[0]=JSESSIONID
balancer->sticky[1]=NULL
balancer->sticky[2]=MYSESSION
4. You will pass balancer->sticky[0] as the name parameter to get_cookie_param
and balancer->sticky[1] as the name parameter to get_path_param.
5. What do you do if balancer->sticky[ ] is NULL? Skip the search?
6. You said that
<cite>
In case the params are omitted the behavior would be
as follows:
stickysession="JSESSIONID" -> balancer->sticky-[0]
stickysession=";jsessionid" -> balancer->sticky-[1]
stickysession="FOO" -> balancer->sticky-[2]
</cite>
Why is FOO stored in balancer->sticky-[2]? Is it because stickysession="FOO"
is the 3rd occurrence of stickysession for this worker or is it because of
the name "FOO"?
7. What is the purpose of [E] [e]? Where will you search for balancer->sticky[2]?
In r->subprocess_env?
Regards
Rüdiger
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Georg von Zezschwitz <gv...@garnix.de>.
Mladen Turk schrieb:
> ...
> or perhaps a different notation ...
> stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION
I like that much more - these "flags" like "[C]" rather raise questions like
"can I add multiple of them?".
What about this?:
"stickysession"
The attribute can occur multiple times within a Balancer directive.
The session identifier is searched in the sequence of the occurrence of
these attributes.
Each value modifier can be preceded by one of the modifiers
"(Cookie|Path|Env)" followed by a colon,
meaning that the identifier is only searched as a Cookie, an URL path
element or in
the environment.
Without a modifier, the identifier will be searched in both the path and
the cookie. (backward compatibility).
The search for the identifier is case-sensitive.
Regards,
Georg
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mladen Turk <mt...@apache.org>.
Jean-Frederic wrote:
>> We could do that then by using existing directive and decide
>> during configure time.
>> For example:
>>
>> stickysession="JSESSIONID [C]" stickysession=";jsessionid [P]"
>
> Does that mean that stickysession="JSESSIONID" will work as it does now?
>
Yes.
> I don't think we need "Case insensitive" because that is the Cookie
> name, the parameter name or the EnvVar name. Those values are normaly
> well defined.
>
That is true for Servlets, but not necessary for others like
PHP or ASP.
> So that would be something:
> stickysession=JSESSIONID stickyurl=jsessionid stickyenv=MYSESSION
>
stickysession=JSESSIONID stickysession=;jsessionid stickysession=MYSESSION
would mean:
balancer->sticky[0]=JSESSIONID
balancer->sticky[1]=;jsessionid
balancer->sticky[2]=MYSESSION
balancer->sticky_case[0]=1
balancer->sticky_case[1]=1
balancer->sticky_case[2]=1
OTOH
stickysession="JSESSIONID [c]" stickysession="MYSESSION [E]"
or perhaps a different notation ...
stickysession=Cookie:JSESSIONID stickysession=Env:MYSESSION
would mean:
balancer->sticky[0]=JSESSIONID
balancer->sticky[1]=NULL
balancer->sticky[2]=MYSESSION
balancer->sticky_case[0]=0
balancer->sticky_case[1]=-1
balancer->sticky_case[2]=1
Regards,
Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jean-Frederic <jf...@gmail.com>.
On Tue, 2007-04-03 at 15:06 +0200, Mladen Turk wrote:
> Plüm wrote:
> >
> >
> > IMHO adding config parameters is no blocker for a backport.
>
> I was under different perception.
>
> >
> >> It is probably more easy to add balancer->stickyurl =
> >> "jsessionid" when
> >> balancer->sticky is "JSESSIONID" and NULL otherwise.
> >>
> >> Or in get_path_param() test for "jsessionid" when balancer->sticky is
> >> "JSESSIONID".
> >
> > I think we should not hardcode JSESSIONID here.
>
> We could do that then by using existing directive and decide
> during configure time.
> For example:
>
> stickysession="JSESSIONID [C]" stickysession=";jsessionid [P]"
Does that mean that stickysession="JSESSIONID" will work as it does now?
I don't think we need "Case insensitive" because that is the Cookie
name, the parameter name or the EnvVar name. Those values are normaly
well defined.
So that would be something:
stickysession=JSESSIONID stickyurl=jsessionid stickyenv=MYSESSION
Cheers
Jean-Frederic
>
> So instead overwriting the balancer->sticky we could create
> an fixed array instead, and have multiple of them.
> The param in square brace is optional and would mean:
>
> [C] -> Cookie Case sensitive
> [c] -> Cookie Case insensitive
> [P] -> URL Path Case sensitive
> [p] -> URL Path Case insensitive
> [E] -> EnvVar Case sensitive
> [e] -> EnvVar Case insensitive
> etc ...
>
> In case the params are omitted the behavior would be
> as follows:
> stickysession="JSESSIONID" -> balancer->sticky-[0]
> stickysession=";jsessionid" -> balancer->sticky-[1]
> stickysession="FOO" -> balancer->sticky-[2]
>
>
> How that looks?
>
> Regards,
> Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mladen Turk <mt...@apache.org>.
Plüm wrote:
>
>
> IMHO adding config parameters is no blocker for a backport.
I was under different perception.
>
>> It is probably more easy to add balancer->stickyurl =
>> "jsessionid" when
>> balancer->sticky is "JSESSIONID" and NULL otherwise.
>>
>> Or in get_path_param() test for "jsessionid" when balancer->sticky is
>> "JSESSIONID".
>
> I think we should not hardcode JSESSIONID here.
We could do that then by using existing directive and decide
during configure time.
For example:
stickysession="JSESSIONID [C]" stickysession=";jsessionid [P]"
So instead overwriting the balancer->sticky we could create
an fixed array instead, and have multiple of them.
The param in square brace is optional and would mean:
[C] -> Cookie Case sensitive
[c] -> Cookie Case insensitive
[P] -> URL Path Case sensitive
[p] -> URL Path Case insensitive
[E] -> EnvVar Case sensitive
[e] -> EnvVar Case insensitive
etc ...
In case the params are omitted the behavior would be
as follows:
stickysession="JSESSIONID" -> balancer->sticky-[0]
stickysession=";jsessionid" -> balancer->sticky-[1]
stickysession="FOO" -> balancer->sticky-[2]
How that looks?
Regards,
Mladen.
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jean-Frederic [mailto:jfclere@gmail.com]
> Gesendet: Dienstag, 3. April 2007 11:32
> An: dev@httpd.apache.org
> Betreff: Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
>
>
> On Tue, 2007-04-03 at 08:30 +0200, Mladen Turk wrote:
> > Georg von Zezschwitz wrote:
> > >
> > > As I (with Rüdigers help :-) ) found out, there is
> already a bug report
> > > to my problem:
> > > #41897 describes the problem that the case-sensitivity of the
> > > "stickysession"-Parameter
> > > does not comply to the Java Servlet Spec (Cookie:
> "JSESSIONID", url
> > > based session
> > > management ";jsessionid").
> > >
> >
> > This is not the breakage of the Servlet-Spec.
> > As section 7.1.1 points out the:
> > "The name of the session tracking cookie *must*
> > be *JSESSIONID*."
> >
> > Next the section 7.1.3 says:
> >
> > "URL rewriting *may* be used by the server as the
> > basis for session tracking. URL rewriting involves
> > adding data, a session ID, to the URL path that is
> > interpreted by the container to associate the
> > request with a session. The session ID must be
> > encoded as a path parameter in the URL string. The
> > name of the parameter *must* be *jsessionid*."
> >
> > So nothing here says anything about case insensitivity,
> > and JseSSioNId would be faulty in that case.
> >
> > IMHO the solution to this problem would be to use the
> > mod_rewrite and setting the BALANCER_SESSION_ROUTE
> > env variable from ;jsessionid path (or what ever).
> > Later in balancer we should check for that if the
> > find_session_route() returns NULL.
> > This way no additional config param would be needed, so
> > it would be backportable to 2.2.
IMHO adding config parameters is no blocker for a backport.
Changing the meaning of existing ones or removing them would be blocker,
but as far as I can tell this has not been proposed.
stickysession would still have the same behaviour as today.
>
> That is a bit complex for the users.
Agreed. Although I am not a friend of reinventing the wheel when things
can be done with existing directives / modules (e.g. regarding the request
to create a directive to set a stickysession Cookie via mod_proxy_balancer
as in http://issues.apache.org/bugzilla/show_bug.cgi?id=38357) I think we
need to provide an easier solution here, especially as this is regarding
a standard configuration with a Tomcat in the backend.
Currently I am undecided about the best way to reach this goal.
>
> It is probably more easy to add balancer->stickyurl =
> "jsessionid" when
> balancer->sticky is "JSESSIONID" and NULL otherwise.
>
> Or in get_path_param() test for "jsessionid" when balancer->sticky is
> "JSESSIONID".
I think we should not hardcode JSESSIONID here. I am not quite sure if this
is possible with Tomcat, but with other app servers you can change the name
of the session identifier, but the "case" behaviour remains the same in this
case: Cookie all in uppercase, URL identifier all in lowercase.
Regards
Rüdiger
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Jean-Frederic <jf...@gmail.com>.
On Tue, 2007-04-03 at 08:30 +0200, Mladen Turk wrote:
> Georg von Zezschwitz wrote:
> >
> > As I (with Rüdigers help :-) ) found out, there is already a bug report
> > to my problem:
> > #41897 describes the problem that the case-sensitivity of the
> > "stickysession"-Parameter
> > does not comply to the Java Servlet Spec (Cookie: "JSESSIONID", url
> > based session
> > management ";jsessionid").
> >
>
> This is not the breakage of the Servlet-Spec.
> As section 7.1.1 points out the:
> "The name of the session tracking cookie *must*
> be *JSESSIONID*."
>
> Next the section 7.1.3 says:
>
> "URL rewriting *may* be used by the server as the
> basis for session tracking. URL rewriting involves
> adding data, a session ID, to the URL path that is
> interpreted by the container to associate the
> request with a session. The session ID must be
> encoded as a path parameter in the URL string. The
> name of the parameter *must* be *jsessionid*."
>
> So nothing here says anything about case insensitivity,
> and JseSSioNId would be faulty in that case.
>
> IMHO the solution to this problem would be to use the
> mod_rewrite and setting the BALANCER_SESSION_ROUTE
> env variable from ;jsessionid path (or what ever).
> Later in balancer we should check for that if the
> find_session_route() returns NULL.
> This way no additional config param would be needed, so
> it would be backportable to 2.2.
That is a bit complex for the users.
It is probably more easy to add balancer->stickyurl = "jsessionid" when
balancer->sticky is "JSESSIONID" and NULL otherwise.
Or in get_path_param() test for "jsessionid" when balancer->sticky is
"JSESSIONID".
Cheers
Jean-Frederic
>
> Regards,
> Mladen.
>
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Georg von Zezschwitz <gv...@garnix.de>.
Mladen Turk schrieb:
> Georg von Zezschwitz wrote:
>> .. #41897 describes the problem that the case-sensitivity of the
>> "stickysession"-Parameter
>> does not comply to the Java Servlet Spec (Cookie: "JSESSIONID", url
>> based session
>> management ";jsessionid").
> This is not the breakage of the Servlet-Spec.
Correct - I was not precise.
> IMHO the solution to this problem would be to use the
> mod_rewrite and setting the BALANCER_SESSION_ROUTE
> env variable from ;jsessionid path (or what ever).
> Later in balancer we should check for that if the
> find_session_route() returns NULL.
> This way no additional config param would be needed, so
> it would be backportable to 2.2.
Using mod_proxy* with Java is no exotic use case, especially with
mod_proxy_ajp.
So, is using the "swiss army knife" here to make mod_proxy* compliant to
the Java
specification really the more elegant solution compared to adding
parameters?
Best regards,
Georg
Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
Posted by Mladen Turk <mt...@apache.org>.
Georg von Zezschwitz wrote:
>
> As I (with Rüdigers help :-) ) found out, there is already a bug report
> to my problem:
> #41897 describes the problem that the case-sensitivity of the
> "stickysession"-Parameter
> does not comply to the Java Servlet Spec (Cookie: "JSESSIONID", url
> based session
> management ";jsessionid").
>
This is not the breakage of the Servlet-Spec.
As section 7.1.1 points out the:
"The name of the session tracking cookie *must*
be *JSESSIONID*."
Next the section 7.1.3 says:
"URL rewriting *may* be used by the server as the
basis for session tracking. URL rewriting involves
adding data, a session ID, to the URL path that is
interpreted by the container to associate the
request with a session. The session ID must be
encoded as a path parameter in the URL string. The
name of the parameter *must* be *jsessionid*."
So nothing here says anything about case insensitivity,
and JseSSioNId would be faulty in that case.
IMHO the solution to this problem would be to use the
mod_rewrite and setting the BALANCER_SESSION_ROUTE
env variable from ;jsessionid path (or what ever).
Later in balancer we should check for that if the
find_session_route() returns NULL.
This way no additional config param would be needed, so
it would be backportable to 2.2.
Regards,
Mladen.