Hi,
On Sat, Jul 21, 2018 at 12:51:53AM +0200, Lukas Tribus wrote:
> Hello,
>
> On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote:
> >
> > Hi LuKas,
> >
> > On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> > > Hello Oliver,
> > >
> > > On Fri, 20 Jul 2018 at 11:55, Olivier
Hello,
On Fri, 20 Jul 2018 at 15:58, Olivier Houchard wrote:
>
> Hi LuKas,
>
> On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> > Hello Oliver,
> >
> > On Fri, 20 Jul 2018 at 11:55, Olivier Houchard
> > wrote:
> > >
> > > Hi,
> > >
> > > On Fri, Jul 20, 2018 at 12:22:20AM +,
On Fri, Jul 20, 2018 at 09:56:23PM +0200, PiBa-NL wrote:
> Thanks Christopher & Willy,
>
> Op 20-7-2018 om 14:26 schreef Willy Tarreau:
> > > Op 20-7-2018 om 10:43 schreef Christopher Faulet:
> > OK finally I've merged it because it obviously fixes a bug.
> > Willy
>
> Confirmed fixed with
Thanks Christopher & Willy,
Op 20-7-2018 om 14:26 schreef Willy Tarreau:
Op 20-7-2018 om 10:43 schreef Christopher Faulet:
OK finally I've merged it because it obviously fixes a bug.
Willy
Confirmed fixed with current master's:
HA-Proxy version 1.8.12-5e100b4 2018/07/20
HA-Proxy version
Hi LuKas,
On Fri, Jul 20, 2018 at 01:53:35PM +0200, Lukas Tribus wrote:
> Hello Oliver,
>
> On Fri, 20 Jul 2018 at 11:55, Olivier Houchard
> wrote:
> >
> > Hi,
> >
> > On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote:
> > > So...is there a way to adapt this patch so it won't cause random
Hello,
I'm trying to setup haproxy for a kind a of weird situation.
Here is my architecture:
- Server S0 and S1 can connect to our client services (which we want
to be proxified)
- Server C0 is in a dedicated network and can't access our client FIX
servers directly. He needs to use S0 proxies
On Fri, 20 Jul 2018 at 13:37, Willy Tarreau wrote:
> Thank you Janusz for testing. I've also merged the other patch that could
> lead to some CLOSE_WAIT that we tested a few months ago. It was different
> but maybe you were suffering from the two causes.
>
I've applied both patches to vanilla
On Fri, Jul 20, 2018 at 01:45:51PM +0200, Tim Düsterhus wrote:
> Perfect. Could you possibly retroactively add a .sha256 file for the
> newest version of each currently supported branch (i.e. 1.8.12, 1.7.11,
> 1.6.14 and 1.5.19)? This would allow me to update a few scripts, without
> having to
On Fri, Jul 20, 2018 at 10:43:13AM +0200, Christopher Faulet wrote:
> Damn! I forgot to check that. We talked about it 30 min ago though!
OK finally I've merged it because it obviously fixes a bug and William
wants to prepare another release which I think is a good idea. We can
revisit this later
Hi Tim,
On Fri, Jul 20, 2018 at 01:40:28PM +0200, Tim Düsterhus wrote:
> Am 20.07.2018 um 10:42 schrieb Willy Tarreau:
> > This one is very interesting because depending on the compiler version
> > the unlikely macro differs and may never detect the failure by never
> > returning < 0! It's very
Hello Oliver,
On Fri, 20 Jul 2018 at 11:55, Olivier Houchard
wrote:
>
> Hi,
>
> On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote:
> > So...is there a way to adapt this patch so it won't cause random SSL
errors and is suitable to apply to the trunk? We don't really want to run a
customised
Willy,
Am 20.07.2018 um 10:50 schrieb Willy Tarreau:
> Makes sense, now merge.
>
Perfect. Could you possibly retroactively add a .sha256 file for the
newest version of each currently supported branch (i.e. 1.8.12, 1.7.11,
1.6.14 and 1.5.19)? This would allow me to update a few scripts, without
Hi
Am 20.07.2018 um 10:42 schrieb Willy Tarreau:
> This one is very interesting because depending on the compiler version
> the unlikely macro differs and may never detect the failure by never
> returning < 0! It's very unlikely to meet this case though.
In fact this already caused a crash:
On Fri, Jul 20, 2018 at 01:30:00PM +0200, Janusz Dziemidowicz wrote:
> I've been running 1.8.12 with this patch for an hour. It seems that it
> helped somewhat, but not entirely. After an hour I still see about 10
> CLOSE_WAIT sockets. The number seems to grow a lot slower, but still
> grows (and
czw., 19 lip 2018 o 11:14 Willy Tarreau napisał(a):
>
> Hi Milan, Janusz,
>
> I suspect I managed to reliably trigger the issue you were facing and
> found a good explanation for it. It is caused by unprocessed bytes at
> the end of the H1 stream. I manage to reproduce it if I chain two layers
>
Hello,
On Wed, 18 Jul 2018 at 14:30, Willy Tarreau wrote:
>
> Hi Tim,
>
> On Wed, Jul 18, 2018 at 01:48:01PM +0200, Tim Düsterhus wrote:
> > This would solve the issue for my use case and should not break anything
> > (a few UNKNOWNs will become TCP6 then).
>
> OK.
>
> > I can rework the patch,
Hi,
On Fri, Jul 20, 2018 at 12:22:20AM +, Thrawn wrote:
> So...is there a way to adapt this patch so it won't cause random SSL errors
> and is suitable to apply to the trunk? We don't really want to run a
> customised build in production...
You don't need the patch, just using
Hi,
Yes i have setuped logging :
listen serveurs_ssp-dispatcher
bind x.x.x.x:80
log x.x.x.x local0
no option log-separate-errors
option httplog
option logasap
no option log-separate-errors
capture request header X-Forwarded-For len 50
capture request header Host len 50
Hello,
In fact I just want the display of the .html extension on my site no longer
displayed
I use haproxy with Nginx, I can make url rewrite with Nginx that works well:
server {
rewrite ^(/.*)\.html(\?.*)?$ $1$2 permanent;
index index.html;
try_files $uri.html $uri/ $uri =404;
}
Hi Tim,
On Thu, Jul 19, 2018 at 11:57:56PM +0200, Tim Duesterhus wrote:
> Currently only md5 signatures are generated. While md5
> still is not broken with regard to preimage attacks, sha256
> clearly is the current secure solution.
>
> This patch should be backported to all supported branches.
On Fri, Jul 20, 2018 at 10:31:33AM +0200, Christopher Faulet wrote:
> Hi Willy,
>
> Here is a patch to fix the compilation of HAProxy with the debug mode
> enabled. Some debug messages were still using the old buffers api.
It was left as an API conversion exercise for the reader :-)
Bah as you
Le 20/07/2018 à 10:38, Willy Tarreau a écrit :
On Fri, Jul 20, 2018 at 10:27:42AM +0200, Christopher Faulet wrote:
In thread_sync_barrier, we exit when all threads have set their own bit in the
barrier mask. It is done by comparing it to all_threads_mask. But we must not
use a simple equality
On Fri, Jul 20, 2018 at 10:33:52AM +0200, Christopher Faulet wrote:
> Hi Willy,
>
> Here is a little patch to fix brackets place of the unlikely macro in http
> code. It must be backported in 1.8.
This one is very interesting because depending on the compiler version
the unlikely macro differs
On Fri, Jul 20, 2018 at 10:27:42AM +0200, Christopher Faulet wrote:
> In thread_sync_barrier, we exit when all threads have set their own bit in the
> barrier mask. It is done by comparing it to all_threads_mask. But we must not
> use a simple equality to do so, becaue all_threads_mask may change.
Hi Willy,
Here is a little patch to fix brackets place of the unlikely macro in
http code. It must be backported in 1.8.
--
Christopher Faulet
>From fc53818025c8681c800e807960af2a6859006014 Mon Sep 17 00:00:00 2001
From: Christopher Faulet
Date: Fri, 20 Jul 2018 09:54:26 +0200
Subject:
Hi Willy,
Here is a patch to fix the compilation of HAProxy with the debug mode
enabled. Some debug messages were still using the old buffers api.
--
Christopher Faulet
>From deb61c7822acbfcc7fe0ff611eee51fd57773e72 Mon Sep 17 00:00:00 2001
From: Christopher Faulet
Date: Fri, 20 Jul 2018
Le 17/07/2018 à 19:39, PiBa-NL a écrit :
Hi Christopher,
Op 17-7-2018 om 10:09 schreef Christopher Faulet:
Could you try to revert the following commit please ?
* ba86c6c25 MINOR: threads: Be sure to remove threads from
all_threads_mask on exit
Without this specific commit the termination
27 matches
Mail list logo
