Hello,
Am 20.07.2017 um 17:28 schrieb rai...@ultra-secure.de:
>
>
>> od -c bomfile.
>
>
> 000 377 376 s \0 e \0 r \0 v \0 e \0 r \0 _ \0
> 020 u \0 p \0 \r \0 \n \0
> 030
>
Obviously haproxy can't match this. Not only because of the BOM, but
also
Am 2017-07-20 14:18, schrieb Jarno Huuskonen:
Can you share how you've configured health checks in haproxy.cfg ?
backend site-back
balance roundrobin
mode http
option httpchk GET /healthcheck.htm HTTP/1.1\r\nHost:\
site.com\r\nConnection:\ close
http-check expect string server_up
On 07/20/2017 02:55 PM, Willy Tarreau wrote:
> So you can have :
> 0 or 1 "listen"
> 0 or 1 "frontend" + 0 or 1 "backend"
>
> Just a few ideas come to my mind :
> - is it possible to store arrays into arrays ? I mean, could we have
> for example core.proxies["foo"].side[FRONT|BACK]
Hi,
On Thu, Jul 20, Andrey Zakabluk wrote:
> frontend http-in
> bind *:4016
> default_backend servers
> mode http
> option httplog
> log global
>option forwardfor
>capture cookie SERVERID len 32
>capture request header Host len 15
>
Hi guys,
On Thu, Jul 20, 2017 at 02:35:22PM +0200, Adis Nezirovic wrote:
> On 07/20/2017 12:17 PM, Thierry FOURNIER wrote:
> > I understand the problem, but I can't accept this patch because it makes
> > the proxies list unusable. Your patch remove the proxies names, and the
> > user cannot have
Hi! I tried
frontend http-in
bind *:4016
default_backend servers
mode http
option httplog
log global
option forwardfor
capture cookie SERVERID len 32
capture request header Host len 15
capture request header X-Forwarded-For len
On 07/20/2017 12:17 PM, Thierry FOURNIER wrote:
> I understand the problem, but I can't accept this patch because it makes
> the proxies list unusable. Your patch remove the proxies names, and the
> user cannot have solution for knowning the real name of the proxies
> now called 1, 2, 3, ...
>
>
Hi,
On Thu, Jul 20, rai...@ultra-secure.de wrote:
> I had a very strange situation earlier.
>
> He have a site behind a haproxy/nginx combination, it has been
> working for years.
> (It's Windows).
>
> However, suddenly I get L7 timeouts.
>
> But curl to the healthcheck URL works perfectly.
>
Hi,
I had a very strange situation earlier.
He have a site behind a haproxy/nginx combination, it has been working
for years.
(It's Windows).
However, suddenly I get L7 timeouts.
But curl to the healthcheck URL works perfectly.
The output I get looks like this:
��server_up
Piping curl
Hi Adis,
Sorry, I dont saw this patch proposal.
I understand the problem, but I can't accept this patch because it makes
the proxies list unusable. Your patch remove the proxies names, and the
user cannot have solution for knowning the real name of the proxies
now called 1, 2, 3, ...
I propose
On Thu, Jul 20, 2017 at 11:15:48AM +0200, Christopher Faulet wrote:
> And because I said that, it happens. I introduced a major bug. It is
> possible to have an infinite loop during states synchronization...
>
> Willy, I produced the patch for the upstream:
>
Le 19/07/2017 à 22:18, Christopher Faulet a écrit :
Because these last weeks, there were several regressions on this part
(the end of the HTTP transaction), I prefer to be careful this time.
Every time I fixed a bug in one side, this broke something else from
another one...
And because I said
12 matches
Mail list logo
