Am 25-07-2015 09:05, schrieb mlist:
Hi Willy, any new on the strange cookie behavior ?
Also I ask you for haproxy configuration problem cannot I found a
solution searching hard on Internet...
To be honest I can't believe this.
Have you tried to read the documentation carefully and more then one
1. We want to redirect all non HTTPS request to HTTPS except some
request (ex: path_beg based) but we want to have exception like this:
If Request = http://<dom1>/(A) -> backend1 (http)
If Request = https://<dom1>/(A) -> SSL Termination -> backend1 (http)
If Request = http://<dom1>/(NOT A) -> Redirect SSL -> SSL
Termination -> backend1 (http)
If Request = https://<dom1>/(NOT A) -> SSL Termination -> backend1
Maybe you get the idea for a possible solution way.
There are best practice for configuration to avoid redundancy in
configuration file but having best performance, 2 front-end + 2
back-end, 2 front-end + 1 back-end, 1 front-end + 1 backend-end ?
2. In a configuration like that in point 1. (with SSL termination with
exception) is a good solution to mix backend :80 with :443 servers
without a risk for redirection loop ? There is as flow chart of
haproxy request-response flow to can evaluate these configurations ?
Maybe you could find some answer in the design-thoughts directory like.
As far as I know there is not yet a flow chart like
You can see the picture when you paste the text into this website.
3. In haproxy.log I see only client request, is there a configuration
to see also backend server response or the only solution is to use
debugging to see all traffic ? Also, I use on command line haproxy -d
to debug, there is a method so we do not need to stop haproxy daemon
to use command line to do debugging ? so we can debug changes on
production haproxy ?
4. what standard syntax haproxy uses for Regular Expression (perl,
# USE_PCRE : enable use of libpcre for regex. Recommended.
5. What about client certificates ? I think haproxy can SSL Terminate
also client certificates verification, is so ? What about client
certificates if backend server have to authenticate client using their
certificate, can haproxy manage this situation passing client
certificates to backend server ?
Thank you in advance.
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: lunedì 20 luglio 2015 12.15
Cc: 'Baptiste'; email@example.com
Subject: Re: cookie prefix strange behavior
On Mon, Jul 20, 2015 at 09:51:28AM +0000, mlist wrote:
>> Hi Baptiste, as you can see using prefix or sticky table we found this
invalid cookie problem.
>> - Why without haproxy in the middle we do not have this problem ? why a
browser send an INVALID cookie ?
>Because it learned it another way, maybe before you installed haproxy,
>maybe on a direct connection or anything.
I'm sure enough this is not the case. After we get this behavior, we
all cookies. After some testing passing only by haproxy for these
get the problem again, with Chrome and with IE.
>> - How we can match absence of prefix ? can be done directly by haproxy ?
> I think haproxy should fix it, yes, otherwise it can continue this way
> forever. That said, it *will* break existing sessions, but if haproxy
> applies load balancing, such session will be broken as well.
> What version is this, 1.6-dev or 1.5 ?
What do you mean with: "it *will* break existing sessions" ? if we
balance web application with haproxy, session coming in must have a
inserted/prefixed by haproxy, I'm wrong ? if so any request with an
cookie is INVALID :D so no session will be broken...
What I mean is that if the cookie is invalid, haproxy cannot use the
to decide what server to send the request to, so it will pick one
the farm which is not necessarily the right one (in fact it has a
chance of picking a wrong one in a farm of N servers). That's why I
that haproxy should fix this when this happens. Most likely the problem
that once a wrong cookie flows from the client to the server, the
will not emit this cookie anymore so no prefixing will occur. For this
reason I think that we should remove the invalid cookies from the
when running in prefix mode.
In order to know exactly how the situation happened, you'll need to
through all the logs affecting the client which exhibited the problem.
cookie flags will indicate when the cookie was inserted/prefixed,
or valid/invalid etc... And maybe we'll find what produces this
It is also possible that the cookie is built by the application using
We compiled from source "HA-Proxy version 1.6-dev2-25f4e3e 2015/07/10"
OK thanks. Do you know if 1.5 also produces the same problem ? It could
be a regression, though I don't remember that we ever touched that area