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...
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
(http)
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 ?
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, POSIX) ?
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.
Best Regards
Roberto
-----Original Message-----
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: lunedì 20 luglio 2015 12.15
To: mlist
Cc: 'Baptiste'; haproxy@formilux.org
Subject: Re: cookie prefix strange behavior
On Mon, Jul 20, 2015 at 09:51:28AM +0000, mlist wrote:
> Hi Willy
>
> >> 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 cleaned
> all cookies. After some testing passing only by haproxy for these domain, we
> get the problem again, with Chrome and with IE.
OK, interesting.
> >> - 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 load
> balance web application with haproxy, session coming in must have a cookie
> inserted/prefixed by haproxy, I'm wrong ? if so any request with an Invalid
> cookie is INVALID :D so no session will be broken...
What I mean is that if the cookie is invalid, haproxy cannot use the cookie
to decide what server to send the request to, so it will pick one server in
the farm which is not necessarily the right one (in fact it has a (N-1)/N
chance of picking a wrong one in a farm of N servers). That's why I think
that haproxy should fix this when this happens. Most likely the problem is
that once a wrong cookie flows from the client to the server, the server
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 requests
when running in prefix mode.
In order to know exactly how the situation happened, you'll need to look
through all the logs affecting the client which exhibited the problem. The
cookie flags will indicate when the cookie was inserted/prefixed, present
or valid/invalid etc... And maybe we'll find what produces this situation.
It is also possible that the cookie is built by the application using
javascript.
> 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
recently.
Willy
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
