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:

Le 09/05/2012 07:04, Baptiste a écrit :
>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 :

- 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

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 ;-)


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).

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.

4.) What do you think to extend

    cook_beg(<name>) <string>


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?


Reply via email to