Hi,
I have checked the documentation but cannot find much information on chkfail's
in there.
Is there any way to check what went wrong when a "chkfail" has occurred?
We use a monitoring-plugin that has thresholds set on chkfail's which shows me
that some machines have multiple chkfail's every d
On Tue, Jun 3, 2014 at 11:28 AM, Michel Hoogervorst
wrote:
> Hi,
>
>
>
> I have checked the documentation but cannot find much information on
> chkfail’s in there.
>
>
>
> Is there any way to check what went wrong when a “chkfail” has occurred?
>
> We use a monitoring-plugin that has thresholds se
Hi,
Thanks for your reply.
This is how our config looks like (I stripped some non-relevant comments and
names):
global
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 2
userhaproxy
group haproxy
Using 1.5-dev25. Sometimes for transitional support, we need to temporarily
use a non-standard port for frontend SSL traffic. Is there anything that
might prevent identical requests from matching the below frontend/backend
if they're sent to :8080 instead of :443?
frontend https-in
bind *:443
Quick question (after writing the email, I realized that there's nothing
quick about it) about the order of processing for "reqidel" and "option
forwardfor" options. First and foremost, we're running HA-Proxy version
1.5-dev24-8860dcd 2014/04/26
Up until a few days ago, we were doing pretty straig
Hi Justin,
On Tue, 03 Jun 2014, 17:56:49 +0200, Justin Rush wrote:
> [...]
> The following is the output and log entry from a request to port 443:
>
> $ curl -k https://proxy.prod/health
> "OK"
>
> haproxy[4424]: 10.20.30.40:53283 [03/Jun/2014:15:49:03.097] https-in~
> app.prod/app1
> 455/0/97/4
Hi Manfred,
On Tue, Jun 3, 2014 at 11:12 AM, Manfred Hollstein
wrote:
>
> Can you try if "curl -k http://proxy.prod:8080/health"; works? If I'm not
> mistaken, https:// implicitly uses port 443, but don't know how the
> explicit :8080 might interfere with that.
>
As I expected, this gets an em
Justin Rush schreef op 3-6-2014 18:19:
Hi Manfred,
On Tue, Jun 3, 2014 at 11:12 AM, Manfred Hollstein
mailto:mhollst...@t-online.de>> wrote:
Can you try if "curl -k http://proxy.prod:8080/health"; works? If
I'm not
mistaken, https:// implicitly uses port 443, but don't know how
Justin Rush schreef op 3-6-2014 18:19:
Hi Manfred,
On Tue, Jun 3, 2014 at 11:12 AM, Manfred Hollstein
mailto:mhollst...@t-online.de>> wrote:
Can you try if "curl -k http://proxy.prod:8080/health"; works? If
I'm not
mistaken, https:// implicitly uses port 443, but don't know how
Hi guys,
> Hi Manfred,
>
>
> On Tue, Jun 3, 2014 at 11:12 AM, Manfred Hollstein
> mailto:mhollst...@t-online.de>> wrote:
>
> Can you try if "curl -k http://proxy.prod:8080/health"; works? If I'm not
> mistaken, https:// implicitly uses port 443, but don't know how the
> explicit :8080
On Tue, Jun 3, 2014 at 12:25 PM, PiBa-NL wrote:
> Can you give it a try with:
> use_backend ssl_app if { hdr_sub(host) -i app.prod:8080 }
>
> Think ive seen at least with sni requests that the (non standard) port is
> part of the sni name indication, not sure about how plain http is handled.
>
Hi there!
On Tue, Jun 3, 2014 at 12:44 PM, Lukas Tribus wrote:
> Justin, can you double check that you are in fact using hdr_sub?
>
My apologies: Through a layer of human-abstraction and another layer of
config sanitization, I discovered that we were using "hdr_end" instead of
hdr_sub. I didn't
On Tue, Jun 3, 2014 at 8:57 AM, Andy Walker wrote:
> Quick question (after writing the email, I realized that there's nothing
> quick about it) about the order of processing for "reqidel" and "option
> forwardfor" options. First and foremost, we're running HA-Proxy version
> 1.5-dev24-8860dcd 201
Oh for dumb... I actually do have an:
option forwardfor except 127.0.0.0/8
in the defaults section, despite the fact that I'd defined it in all of the
frontends that we have. Big oversight! My apologies :)
So, removing that line from the defaults section actually did fix the
issue, but I'll prob
Hello,
I don't read all the content of your patch, but a little thing get my
mind: you're using a "regex_t". Haproxy can be compiled with standard
regex, pcre regex or pcre regex with JIT. You must use the "struct
my_regex" defined in "include/common/regex.h" to use compliant system.
regcomp i
Therry:
I noticed that both regex_t and my_regex were used throughout the
code, and was not sure what the policy was. So I take it new code
should be using my_regex. Should we also change the old code to
my_regex?
On Tue, Jun 3, 2014 at 4:12 PM, Thierry FOURNIER
wrote:
> Hello,
>
> I don't read
Hello
Is it possible to do {response,request} header whitelisting in HAProxy?
Initially I want to allow only certain headers from the backend.
Regards,
Oskar Liljeblad
17 matches
Mail list logo
