Hi Jean,
I finally found it by carefully unrolling the execution based on your core.
It's a regression introduced in 1.7 while fixing a problem of missing cookies
in logs when doing a tarpit... I could finally reproduce it and fix it with
the attached patch.
Thanks a lot for all the details you
Hi Jean,
On Sun, May 28, 2017 at 10:15:28AM +, Jean LUBATTI wrote:
> There was a tcp-request inspect-delay of 2s in the configuration when running
> the repro, so it should be fine.
OK. However, I totally fail to reproduce the problem here using your config,
the build options I found in your
There was a tcp-request inspect-delay of 2s in the configuration when running
the repro, so it should be fine.
Sent from my iPhone
> On 28 May 2017, at 11:41, Willy Tarreau wrote:
>
> Hi Jean,
>
>> On Sun, May 28, 2017 at 09:15:56AM +, Jean LUBATTI wrote:
>> Hi Willy,
>>
>> I
Hi Jean,
On Sun, May 28, 2017 at 09:15:56AM +, Jean LUBATTI wrote:
> Hi Willy,
>
> I just tried the line "tcp-request content capture req.hdrs_bin len 2000" in
> the config but I get:
>
> [ALERT] 147/073131 (13352) : parsing [/etc/haproxy/haproxy.cfg:42] :
> 'tcp-request content capture'
Hello Jean,
On Fri, May 26, 2017 at 01:00:17PM +, Jean LUBATTI wrote:
> Hello,
>
> When using a vulnerability scanner on haproxy 1.7.5, we discovered a scenario
> under which the haproxy segfaults.
>
> Unfortunately, this is a "bundled" scanner whith no access to the exact
> requests, and
Hello,
When using a vulnerability scanner on haproxy 1.7.5, we discovered a scenario
under which the haproxy segfaults.
Unfortunately, this is a "bundled" scanner whith no access to the exact
requests, and the haproxy terminates the SSL for https, so not easy to capture
the actual traffic,
6 matches
Mail list logo