Hi all,
On 09-05-2012 14:08, Willy Tarreau wrote:
Hi Cyril,
On Wed, May 09, 2012 at 08:55:45AM +0200, Cyril Bonté wrote:
Hi,
Le 09/05/2012 07:04, Baptiste a écrit :
>Hi,
>
>Yes, appsession has been obsoleted by "cookie" and "set-cookie"
stick
>tables pattern extraction (in HAProxy 1.5-dev7 as far as I
remember).
>As an example:
>
> stick-table type string len 32 size 10K
> stick store-response set-cookie(PHPSESSID)
> stick on cookie(PHPSESSID)
>
>or, better, if your cookie is presented on the query string by the
key
>"session_id", then this would do the persistence as well:
> stick on url_param(session_id)
I may be wrong but I think there are still some points where
"appsession" can't be replaced by stick tables.
- for example the use of path parameters :
http://example.com/url;jsessionid=XXX
- the use of cookie prefixes :
I don't see how to match cookies (or path parameters/query string)
like
ASPSESSIONIDXXX=<value> (where XXX is dynamic).
That was one of the primary Idea, dynamic cookie/url Sessions.
Maybe it still requires some development if we want to replace it by
an
equivalent with stick tables.
You're perfectly right.
Also the logic in appsession is somewhat different to the logic in
stick-tables. For instance, if a client comes with an inexistant
cookie
and the server replaces it, then the client's cookie won't be
learned.
With the "request-learn" option, it's even trickier. The client's
cookie
will be learned from the URL parameter unless the server overwrites
it
in the response.
I think it is fairly acceptable to change this behaviour a bit
provided
that what currently works still works. After all it's not really a
problem
if we store old expired entries in the table once in a while. But I
want
to insist (like you did) on the fact that there is not a 1:1 match
right
now.
I would like to reuse as much code as possible from the current haproxy
framework.
I like the idea from Baptiste
###
stick-table type string len 32 size 10K
stick store-response set-cookie(PHPSESSID)
stick on cookie(PHPSESSID)
###
which "only" must be added to the appsession options ;-)
http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=doc/configuration.txt;h=9aa7e1c6d27b373aece27ef61b965d0b62a9b5a2;hb=HEAD#l1147
What I currently see that we need is following:
1.) We need a similar function like appsession_refresh() to clean up
"OLD" entries from
the $STORE (peers, anything else).
http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=src/appsession.c;h=ec97336e3f6873741c75e39c052fbe6df36473b3;hb=HEAD#l86
2.) Is there a similar hash function in Haproxy like
appsession_hash_f() to avoid duplicate functions.
http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=src/sessionhash.c;h=80683900a1085e6f8e0d84555495576fd77ed423;hb=HEAD#l26
How difficult is it to use Consistent Hash implementation, is it
useful to replace the appsession_hash_f with chash?
http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=src/lb_chash.c;h=58f1c9eaae8b15e984b9a5a341b2bdb11d8656f1;hb=HEAD
3.) Add the appsession to the balance keyword.
http://haproxy.1wt.eu/git?p=haproxy.git;a=blob;f=doc/configuration.txt;h=9aa7e1c6d27b373aece27ef61b965d0b62a9b5a2;hb=HEAD#l1240
4.) What do you think to extend
cook_beg(<name>) <string>
with
cook_beg(<name>) <string> [len] [prefix] [request-learn]
[<save_the_rest_of_the_cookie_after_prefix]
scook_beg(<name>) <string> [len] [prefix]
[<save_the_rest_of_the_cookie_after_prefix]
or with regex or so.
I would start to dig again into haproxy framework and try to replace
the dedicated solutions in
**/appsession* **/appsession* with common haproxy functions.
Another solution could be that the appsession is one of the first
haproxy plugin ;-) ;-)
What are your opinions?
Is there the possibility for a chat or irc session?
Cheers
Aleks
