Move ../test/recipes/80-test_ssl_new.t outside of the build root. That means
"throw out". rm -f ../test/recipes/80-test_ssl_new.t also works.
‐‐‐ Original Message ‐‐‐
On Tuesday, September 15, 2020 8:28 PM, vcjouni
wrote:
> Hi,
>
> I tested for openssl-1.1.1g.tar.gz from
git bisect says that this regression was caused
by commit c89077713915f605eb5d716545f182c8d0bf5581
This makes little sense to me, since that commit doesn't touch anything
even slightly related.
As far as I can tell, the proximate issue is that PATCH is not a
"well-known method" to HAproxy,
One of our configurations includes the following snippet:
acl allowed_method method HEAD GET POST PUT PATCH DELETE OPTIONS
ttp-request deny if !allowed_method
In HAproxy 2.2.2 and below, this correctly blocks all requests that are not
HEAD, GET, PUT, POST, PATCH, DELETE, or OPTIONS.
In HAproxy
Hi List,
I'd like to discuss something that's bothering me for quite some time
now: The naming, namespacing and discoverability of fetches and converters.
Frankly, it's a small mess right now. I assume this is due to historic
growth an features being added over time. Let me give a few examples:
Il 16/09/20 18:08, Axel DUMAS ha scritto:
At the boot, HAProxy say "Starting frontend srv_java: cannot bind socket
[192.168.0.19:26000]".
> ...
In addition, when I just use the command "sudo service haproxy restart",
HAProxy works very well.
Hi, Axel!
I would try the following.
Create a
On Thu, Sep 17, 2020 at 10:56:39AM +0200, Maciej Zdeb wrote:
> Hi,
>
> Our config is quite complex and I'm trying to narrow it down. It is
> occurring only on one production haproxy cluster (which consists of 6
> servers in each of two data centers) with significant load - crashes occurs
> on
Hi,
Our config is quite complex and I'm trying to narrow it down. It is
occurring only on one production haproxy cluster (which consists of 6
servers in each of two data centers) with significant load - crashes occurs
on random servers so I would exclude memory corruption.
I'm suspecting SPOE
Hi guys,
On Thu, Sep 17, 2020 at 11:05:31AM +1000, Igor Cicimov wrote:
(...)
> > Coredump fragment from thread1:
> > (gdb) bt
> > #0 0x55cbbf6ed64b in h2s_notify_recv (h2s=0x7f65b8b55130) at
> > src/mux_h2.c:783
So the code is this one:
777 static void __maybe_unused
8 matches
Mail list logo