How it works?
I mean if matrix is built on the fly, schedule is inside matrix, right? How
github can have prior knowledge when to run scheduled jobs then
On Fri, Nov 20, 2020, 4:16 AM Tim Duesterhus wrote:
> Willy,
> Ilya,
>
> find two patches improving the CI.
>
> 1) This lays the foundation
Willy,
Ilya,
find two patches improving the CI.
1) This lays the foundation to check the workflow trigger in the matrix
generator Python script, allowing us to move less important jobs into
a daily / weekly schedule.
2) This cleans up the Windows CI. I've made sure to re-use as much as
This is a preparation to later run some matrix entries on schedule only.
Within the matrix.py script it can now be detected whether the workflow is
running on schedule by using:
if build_type == "schedule":
matrix.append(...)
---
.github/matrix.py | 9 +
This patch cleans up the Windows CI to look more similar to the refactored
Linux CI on GitHub Actions.
It switches the environment set-up from some manual cygwin setup via choco to
the msys2/setup-msys2@v2 action which just works and allows later steps to look
like any others without need to
I'd like to get rid of OPENSSL_VERSION as much as possible.
what would be better for guarding TLS13 ciphers manipulation ?
approach 1 (macro defined in openssl-compat.h)
#if ((OPENSSL_VERSION_NUMBER >= 0x10101000L) &&
!defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL))
#define
Ilya,
Am 19.11.20 um 21:00 schrieb Илья Шипицин:
> next CI additions.
>
Thanks, the results of the changes look good to me.
Can you please split the first patch into 2 or 3 different patches,
though? It makes the commit history a bit cleaner and if they are all
pushed together it will be
Hello,
next CI additions.
Ilya
From bdb90411323c5d87dca8a10bc105ede3e46ab20e Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Fri, 20 Nov 2020 00:58:46 +0500
Subject: [PATCH 2/2] CI: travis-ci: remove builds migrated to GH actions
---
.travis.yml | 20
1 file changed,
Thanks :)
On Fri, Nov 20, 2020, 12:01 AM William Lallemand
wrote:
> On Thu, Nov 19, 2020 at 12:58:06AM +0500, Илья Шипицин wrote:
> > ping :) ?
> >
> > сб, 14 нояб. 2020 г. в 02:04, Илья Шипицин :
> >
> > > Hi.
> > >
> > > next define improvement.
> > >
> > > Ilya
> > >
>
> Thanks, merged.
>
>
On Thu, Nov 19, 2020 at 12:58:06AM +0500, Илья Шипицин wrote:
> ping :) ?
>
> сб, 14 нояб. 2020 г. в 02:04, Илья Шипицин :
>
> > Hi.
> >
> > next define improvement.
> >
> > Ilya
> >
Thanks, merged.
--
William Lallemand
Tim.
Cool big thank to clarify that for me.
Regards
Aleks
On 19.11.20 17:03, Tim Düsterhus wrote:
Aleks,
Am 19.11.20 um 16:53 schrieb Aleksandar Lazic:
When a H2 client send the header in lowercase then and h1 in mixed-case
could the "del-header"
line not match when it's only written in
Aleks,
Am 19.11.20 um 16:53 schrieb Aleksandar Lazic:
> When a H2 client send the header in lowercase then and h1 in mixed-case
> could the "del-header"
> line not match when it's only written in lowercase or mixed-case .
HTTP headers are defined to be case-insensitive. You quoted it yourself:
Hi.
On 19.11.20 16:16, Maciej Zdeb wrote:
Hi,
Alaksandar I've looked into code and... :)
Great ;-)
śr., 18 lis 2020 o 15:30 Aleksandar Lazic mailto:al-hapr...@none.at>> napisał(a):
Can you think to respectthe '-i'.
Hi,
Alaksandar I've looked into code and... :)
śr., 18 lis 2020 o 15:30 Aleksandar Lazic napisał(a):
> Can you think to respectthe '-i'.
>
> http://git.haproxy.org/?p=haproxy.git=search=HEAD=grep=PAT_MF_IGNORE_CASE
>
I'm not sure if I understand you correctly, but in case of http-request
Dear web professional,
We invite you to participate in a research study conducted at Ruhr University
Bochum (Germany) in cooperation with Leibniz University Hannover (Germany) and
the University of Michigan (USA). We found your email address
(haproxy@formilux.org) on the website
Christopher,
Am 19.11.20 um 11:47 schrieb Christopher Faulet:
> Le 19/11/2020 à 10:49, Tim Düsterhus, WoltLab GmbH a écrit :
>> John,
>>
>> Am 19.11.20 um 06:57 schrieb John Lauro:
>>> A couple of possible options...
>>> You could use tcp-request inspect-delay to delay the response a
>>> number
Le 19/11/2020 à 10:49, Tim Düsterhus, WoltLab GmbH a écrit :
John,
Am 19.11.20 um 06:57 schrieb John Lauro:
A couple of possible options...
You could use tcp-request inspect-delay to delay the response a number of
seconds (and accept it quick if legitimate traffic).
I believe the
John,
Am 19.11.20 um 06:57 schrieb John Lauro:
> A couple of possible options...
> You could use tcp-request inspect-delay to delay the response a number of
> seconds (and accept it quick if legitimate traffic).
I believe the tcp-(request|response) rules only apply to the very first
buffer of a
17 matches
Mail list logo
