Re: Being sticky to a host, but not to a port

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