Re: Bug 41897 / Session-Stickiness with mod_proxy_balancer
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 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 @@ stickysession - -Balancer sticky session name. The value is usually set to something -like JSESSIONID or PHPSESSIONID, -and it depends on the backend application server that support sessions. +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 Cookie, +Path or Env 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 JSESSIONID or PHPSESSIONID, e.g. + +stickysession=Cookie:JSESSIONID + stickysession=Path:;jsessionid + +for Java Servlets and depends on the backend application server +that support sessions. timeout 0 @@ -721,7 +731,7 @@ A sample balancer setup ProxyPass /special-area http://special.example.com/ smax=5 max=10 - ProxyPass / balancer://mycluster/ stickysession=jsessionid nofailover=On + ProxyPass / balancer://mycluster/ stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid nofailover=OnBalancerMember http://1.2.3.4:8009 Index: docs/manual/mod/mod_proxy.html.en === --- docs/manual/mod/mod_proxy.html.en (revision 526077) +++ docs/manual/mod/mod_proxy.html.en (working copy) @@ -892,9 +892,19 @@ stickysession - -Balancer sticky session name. The value is usually set to something -like JSESSIONID or PHPSESSIONID, -and it depends on the backend application server that support sessions. +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 Cookie, +Path or Env 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 JSESSIONID or PHPSESSIONID, e.g. + +stickysession=Cookie:JSESSIONID + stickysession=Path:;jsessionid + +for Java Servlets and depends on the backend application server +that support sessions. timeout 0 @@ -906,7 +916,7 @@ A sample balancer setup ProxyPass /special-area http://special.example.com/ smax=5 max=10 - ProxyPass / balancer://mycluster/ stickysession=jsessionid nofailover=On + ProxyPass / balancer://mycluster/ stickysession=Cookie:JSESSIONID stickysession=Path:;jsessionid nofailover=On BalancerMember http://1.2.3.4:8009 Index: docs/manual/new_features_2_4.xml === --- docs/manual/new_features_2_4.xml(revision 526077) +++ docs/manual/new_features_2_4.xml(working copy) @@ -39,8 +39,12 @@ Module Enhancements - + + mod_proxy + Extension of the stickysession attribute in ProxyPass to allow + multiple definitions and to specify a prefix to the value like + 'Path', 'Cookie' or 'Env' to limit the search. + Index: docs/manual/new_features_2_4.html.en === --- docs/manual/new_features_2_4.html.en(revision 526077) +++ docs/manual/new_features_2_4.html.en(working copy) @@ -40,7 +40,12 @@ Module Enhancements - + + mod_proxy + Extension of the stickysession attribute in ProxyPass to allow + multiple definitions and to specify a prefix to the value like + 'Path', 'Cookie' or 'Env' to limit the search. + Program Enhancements Index: CHANGES === --- CHANGES (revision 52
Re: mod_ftp enhancements - group directories
On Apr 5, 2007, at 7:16 PM, Filip Hanik - Dev Lists wrote: I would like to propose two enhancements to mod_ftp. The same way we have FTPJailUser and CreateHomeDir directives, we would need FTPJailGroup and CreateGroupDirs directives. This would allow us manage FTP files based on groups, rather than single individual users. Of course, this would only make sense for those auth mechanisms that support the concept of "groups" Thoughts? Anyone interested? (too far down the java trench to be capable of providing a patch) Filip
Further Suggestion for easier Session Stickiness
Hi, I'd like to suggest another extension for mod_proxy*: I always disliked to configure the router name at both the servlet container like Tomcat as well as at the frontend server. The names even have to be exactly the same, difficult... :-). Particulary, I like to copy the Tomcat configuration file from one server to the other, and tend to forget changing jvmRoute - the only difference. So, I want to suggest to make this more user friendly. I can think of 3 approaches: 1) Checking in mod_proxy* if the configured route extension on a "Set-Cookie" by the backend server matches the router name and log an error otherwise. This would be helpful for users to understand why stickiness is not working. 2) Actively correct a wrong/missing ".router-name" value in Set-Cookie directives of backend connections. 3) Encourage the user to omit the "jvmRoute"-setting in the backend, add the routername on Set-Cookie in mod_proxy, and remove the router-name on incoming cookies before passing them to the backend. My suggestion would be to add another attribute to ProxyPass, e.g. "cookies=(check|pass|correct|manage) "pass" would be the current behaviour. "check" should be the default (to help people when configuring their server) "correct" corrects / adds wrong / missing cookie routes "manage" like "correct", but does not pass the router name to the backend. Is a patch like that welcome for trunk? Cheers, Georg
mod_ftp "named virtual hosts"?
I've given some thought to the desire for mod_ftp to support different host contexts, and came up with this... What about modifying mod_ftp USER directive to accept username in the format of [EMAIL PROTECTED], and tokenize user as the username, host as the http-ish Host: virtual host name? If this feature were enabled, 'USER user' would simply be rejected. Thoughts?
Re: mod_ftp "named virtual hosts"?
On Fri, 06 Apr 2007 15:25:03 -0500 "William A. Rowe, Jr." <[EMAIL PROTECTED]> wrote: > I've given some thought to the desire for mod_ftp to support different > host contexts, and came up with this... > > What about modifying mod_ftp USER directive to accept username in the > format of [EMAIL PROTECTED], and tokenize user as the username, host as the > http-ish Host: virtual host name? Sounds fair, provided the protocol doesn't assign some (different) semantics to that. > If this feature were enabled, > 'USER user' would simply be rejected. Ugh. Better to make that a default vhost. As in an HTTP/1.0 request without a Host: header. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
Re: Further Suggestion for easier Session Stickiness
On 04/06/2007 05:02 PM, Georg von Zezschwitz wrote:
> Hi,
>
> I'd like to suggest another extension for mod_proxy*:
> I always disliked to configure the router name at both the servlet
> container like Tomcat
> as well as at the frontend server.
> The names even have to be exactly the same, difficult... :-).
>
> Particulary, I like to copy the Tomcat configuration file from one
> server to the other,
> and tend to forget changing jvmRoute - the only difference.
>
> So, I want to suggest to make this more user friendly.
>
> I can think of 3 approaches:
>
> 1) Checking in mod_proxy* if the configured route extension on a
> "Set-Cookie" by
>the backend server matches the router name and log an error otherwise.
>This would be helpful for users to understand why stickiness is not
> working.
>
> 2) Actively correct a wrong/missing ".router-name" value in Set-Cookie
> directives of
>backend connections.
>
> 3) Encourage the user to omit the "jvmRoute"-setting in the backend, add
> the routername
>on Set-Cookie in mod_proxy, and remove the router-name on incoming
> cookies before
>passing them to the backend.
I am not really in favour to reinvent the wheel if things can be already done
with other modules.
1), 2), 3) boil down to:
The administrator did not take enough care to synchronize its Tomcat
configuration
with its httpd configuration. If you want to avoid this, better leave your hands
off the Tomcat configuration, omit the jvmRoute setting and set your own cookie
inside
of httpd to take care of sticky sessions:
Header add Set-Cookie "MYCOOKIE=SOMEVALUE.%{BALANCER_WORKER_ROUTE}e; path=/;"
env=BALANCER_ROUTE_CHANGED
This does the right thing on any of your n front end httpds and with any of
your m
backend Tomcats. So your Tomcat config does not need to be different on
different boxes
because of sticky sessions and the directive above can be the same on each of
your httpd boxes.
Of course this does NOT work if the client does not support cookies.
But this wouldn't work with your suggestion either and as far as I understand
you
it is not your intention to make this work.
Regards
Rüdiger
Re: mod_ftp "named virtual hosts"?
fre 2007-04-06 klockan 21:37 +0100 skrev Nick Kew: > > What about modifying mod_ftp USER directive to accept username in the > > format of [EMAIL PROTECTED], and tokenize user as the username, host as the > > http-ish Host: virtual host name? > > Sounds fair, provided the protocol doesn't assign some (different) > semantics to that. FTP as such doesn't assign any semantic on the syntax of usernames, but very many FTP firewalls/proxies do... The proposed [EMAIL PROTECTED] is in fact the most common FTP proxy method, meaning connect as user on host, and to login using a [EMAIL PROTECTED] style login via such proxy may be a little awkward if it at all works.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Chunked transfer encoding on responses.
Have a question about past design decisions regarding Apache. My question has come about due to a slightly heated discussion over chunked transfer encoding and its application to response content. In the mod_wsgi module I am implementing for Apache I preserve the default behaviour of Apache which is not to switch on chunked transfer encoding for response content. Because the Python WSGI specification that the module is implementing an adapter for doesn't itself provide a way for an application to indicate that it wants chunked transfer encoding to be used, I have as a convenience provided a directive to control it. The default for the directive is Off (preserving default behaviour of Apache) with other values being On, which is always enable it, ie., set r->chunked to 1 always, and Auto, which will only set r->chunked to 1 if there is no content length header provided for the response by the application. On the WSGI list though, one person has labeled the directive as pointless. Their belief is that a quality HTTP server supporting HTTP/1.1 should always behave in the Auto mode above. Ie., if content length header has not been specified, that the web server should by itself decide to enable chunked transfer encoding. Obviously then he would have to feel that the default behaviour of Apache is wrong. Thus my question is, why when Apache was updated to support HTTP/1.1 did it just preserve the HTTP/1.0 type behaviour and not in cases where it could automatically apply chunked transfer encoding to the response, apply it? The person on the WSGI list is more or less claiming that there would be no harm in a web server always applying chunked transfer encoding to a response which doesn't specify a content length, of course providing it is a HTTP/1.1 client, but something tells me that this doesn't sound quite right and there must be good reasons why Apache doesn't do it. Is this persons claim reasonable, or are there good reasons why one wouldn't want to use chunked transfer encoding on responses with no content length header and thus why Apache requires r->chunked to be set explicitly by an application to enable it. Thanks in advance for any feedback and hopefully this question about how Apache is designed isn't seen as being off topic for the list. :-) Graham
