Hi,
Willy Tarreau wrote:
The prefix is :
- always stripped from any request by a backend which declares
"cookie XXX prefix"
- always applied to any response by a backend which declares
"cookie XXX prefix" when a server returns such a cookie AND
has a cookie value assigned.
The issue can come from servers receiving an expired session and
who wants to reinitialise a new one. They will then emit a new
set-cookie with a new cookie value which will not be prefixed,
and the stickiness will be lost.
So, if the user's session expired, that's probably OK. Their session
will be destroyed anyway, so if they go to a new backend, that won't matter.
Since the prefix/cookie in your example below is set on the way in, I
assume that on the next request (after the session has been re-created),
they'd go to the same backend?
Another solution would be to simply use cookie insertion mode.
Which option are you illustrating in the sample config below? I'm not
sure I fully understand the implications of using prefix vs. insertion
mode here.
Below is the prefix mode. If you want to work in insertion mode,
remove all "cookie XXX prefix" lines and uncomment the
"cookie XXX insert" line.
Right, thanks!
That way
you don't have to worry whether your application will set the cookie
again or not.
So, in fact most users will be anonymous (no session) and don't strictly
need to be sticky to a server, even. When they log in, a cookie
(beaker.session) is set by the application. The application won't trip
up on other cookie values.
I see, but given that you already want to stick on a farm anyway, you
have to set that. It should not be a big trouble because the anonymous
users will just stick to a farm, no to a server.
Yes, that was my "simplification". :)
You could even improve
by using "cookie XXX insert indirect postonly". It will only add a cookie
on responses to POST requests, which most often are the first login
request.
Good plan.
Thanks a lot!
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
