[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haproxy
Subject:    Re: acl matching cookies
From:       Anze <anzenews () volja ! net>
Date:       2010-07-24 14:16:40
Message-ID: 201007241616.40124.anzenews () volja ! net
[Download RAW message or body]


Wow, that was fast! 

Thank you for the answer. This does sound like a better idea... :)

But the main question remains the same: how do I match a cookie? I know I can 
match headers or RDP cookies, but... Wait I sec, should match cookies as 
"Cookie:" headers? Khm, that hasn't occured to me... :D

Thanks again, I think I'll be able to fix it now. :)

Anze


On Saturday 24 July 2010, Willy Tarreau wrote:
> Hi Anze,
> 
> On Sat, Jul 24, 2010 at 03:10:21PM +0200, Anze wrote:
> > Hi all!
> >
> > I hope this is not too "newbie" question, but... is it possible to
> > redirect to a specified backend whenever a predefined value is found in a
> > cookie? (or at least, when a predefined cookie is found at all?) I have
> > read through the docs and ACLs don't seem to be able to match the
> > cookies...
> >
> > I am trying to find a way to test new versions of my app (final checks)
> > before they go live.
> >
> > The idea was this:
> > - remove check.txt, thus taking server down
> > - upgrade web app on that server
> > - set a special cookie in my browser
> > - go to haproxy, it should see the cookie and redirect to "down" server
> > - test the app
> > - when satisfied: `touch check.txt` and upgrade others too
> >
> > Is this possible?
> > 1) can haproxy redirect to "down" server?
> > 2) can it redirect based on a cookie? (I wouldn't want to hardcode IPs
> > and URLs can't be changed)
> 
> all you have described is possible but needlessly complicated. You should
> simply use the "force-persist" statement. It was designed exactly for your
> usage. You set the persistence cookie in your browser so that it can go to
> the server you want to test, and you match anything in the request which
> identifies your browser, as opposed to anyone else's. Most often, the
>  source IP address or a second cookie are used. That way, you can safely
>  test the down server from your browser while nobody else sees it.
> 
> Regards,
> Willy
> 


[prev in list] [next in list] [prev in thread] [next in thread]