On Sun, Jan 03, 2021 at 10:54:43PM +0100, Tim Duesterhus wrote:
> This patch fixes GitHub issue #1024.
Merged, thanks!
Willy
Hi Tim,
On Mon, Jan 04, 2021 at 12:58:25AM +0100, Tim Duesterhus wrote:
> Willy,
> Thayne,
>
> find the patch below.
>
> I am adding Thayne as CC as it was your commit that uncovered the issue and
> the
> crash happened in a function you wrote. Maybe you might want to add some
> additional
Hi Tim,
FWIW, I've just merged your two cleanups as they were independent on the
gcc-specific part.
Thanks,
Willy
NFP WORKSHOPS
18 Blake Street, York YO1 8QG 01133 280988
Affordable Training Courses for Charities, Schools & Public Sector
Organisations
This email has been sent to haproxy@formilux.org
CLICK TO UNSUBSCRIBE FROM LIST
Alternatively send a blank e-mail to unsubscr...@nfpmail2001.co.uk
add base support for url encode following RFC3986, supporting `query`
type only.
- add test checking url_enc/url_dec/url_enc
- update documentation
- leave the door open for future changes
this should resolve github issue #941
Signed-off-by: William Dauchy
---
changed in v2:
- adding support
Hi William,
A few comments below.
On Tue, Jan 05, 2021 at 12:08:58PM +0100, William Dauchy wrote:
> diff --git a/src/http_conv.c b/src/http_conv.c
> index 4afa6a2fd..0fded0cc7 100644
> --- a/src/http_conv.c
> +++ b/src/http_conv.c
> @@ -268,6 +268,83 @@ static int sample_conv_url_dec(const
there was an extra `s` added to the `var_check_arg` function
Signed-off-by: William Dauchy
---
src/flt_spoe.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/flt_spoe.c b/src/flt_spoe.c
index 45370fee6..bfd6f4fbf 100644
--- a/src/flt_spoe.c
+++ b/src/flt_spoe.c
Hi Tim,
Thanks for the review.
On Tue, Dec 22, 2020 at 5:57 PM Tim Düsterhus wrote:
> > +url_enc([])
> > + Takes a string provided as input and returns the encoded version as
> > output.
> > + The input and the output are of type string. By default the type of
> > encoding
> > + is meant
On Tue, Jan 5, 2021 at 5:59 PM Willy Tarreau wrote:
> > I used to think most people use `use_openssl=1` and wondered why it
> > was not the default, but I recently discovered a large setup not
> > making use of tls. The market is however strongly moving towards end
> > to end encryption so I
On Tue, Jan 05, 2021 at 06:10:41PM +0100, Tim Duesterhus wrote:
> Rephrase the message to no longer talk about something that "is no longer
> supported", but about what actually *is* supported.
Thanks, I like this output better than the previous one and just merged it.
That doesn't mean I'm still
On Tue, Jan 05, 2021 at 06:17:56PM +0100, Tim Duesterhus wrote:
> haproxy: $(OPTIONS_OBJS) $(OBJS)
> $(cmd_LD) $(LDFLAGS) -o $@ $^ $(LDOPTS)
> +ifeq ($(USE_OPENSSL),)
> + $(warning Building without TLS support. Add USE_OPENSSL to add support
> for TLS encrypted connections.)
> +endif
>
Add a warning to the `haproxy` target when building without USE_OPENSSL.
---
Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/Makefile b/Makefile
index 4e6c834ed..e60b7d3c8 100644
--- a/Makefile
+++ b/Makefile
@@ -912,6 +912,10 @@ endif
haproxy: $(OPTIONS_OBJS) $(OBJS)
Sorry, previous mail left too early :-)
On Tue, Jan 5, 2021 at 5:59 PM Willy Tarreau wrote:
> Note, they still have to enter the target operating system so minimal
> reading is necessary. But this can be addressed in the makefile's help
> message which is their first contact indicating them what
Willy,
Am 05.01.21 um 17:22 schrieb Willy Tarreau:
> Given that haproxy's main target is HTTP and that these days it often
> comes with SSL (and it doesn't seem like it's going to revert soon),
> I was wondering if it would be a good idea for 2.4 and onwards to preset
> USE_OPENSSL=1 by default.
hello,
another spelcheck fixes.
Ilya
From 6f6d56943c6bf41a2b33cc572c9eab679dcdb5e1 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Tue, 5 Jan 2021 22:10:46 +0500
Subject: [PATCH] CLEANUP: assorted typo fixes in the code and comments
This is 14th iteration of typo fixes
---
ping
On Wed, Dec 30, 2020, 5:50 PM Илья Шипицин wrote:
>
>
> On Wed, Dec 30, 2020, 4:23 PM Tim Düsterhus wrote:
>
>> Ilya,
>>
>> Am 30.12.20 um 11:28 schrieb Илья Шипицин:
>> > all tools are built in separate job.
>>
>> Looks good to me in general. However for this one it would probably be
On Tue, Jan 05, 2021 at 05:44:27PM +0100, William Dauchy wrote:
> Hi Willy,
>
> On Tue, Jan 5, 2021 at 5:23 PM Willy Tarreau wrote:
> > as I suspected in issue #1020, another user got trapped not enabling
> > SSL when building from sources (probably for the first time, as it
> > happens to
Hi all,
as I suspected in issue #1020, another user got trapped not enabling
SSL when building from sources (probably for the first time, as it
happens to everyone to build haproxy for the first time).
Given that haproxy's main target is HTTP and that these days it often
comes with SSL (and it
Hi Ilya,
On Tue, Jan 05, 2021 at 08:11:00PM +0500, ??? wrote:
> ping
I thought you were going to change something regarding this below:
> >> Looks good to me in general. However for this one it would probably be
> >> sufficient to run it on schedule once a day / week or so. The
On Tue, Jan 05, 2021 at 05:36:30PM +0100, Tim Düsterhus wrote:
(...)
> The patch in this state is okay for me, you can take it.
Perfect, now merged, thanks for the explanation!
Willy
Hi Willy,
On Tue, Jan 5, 2021 at 5:23 PM Willy Tarreau wrote:
> as I suspected in issue #1020, another user got trapped not enabling
> SSL when building from sources (probably for the first time, as it
> happens to everyone to build haproxy for the first time).
>
> Given that haproxy's main
On Tue, Jan 05, 2021 at 05:34:46PM +0100, Tim Düsterhus wrote:
> Willy,
>
> Am 05.01.21 um 17:22 schrieb Willy Tarreau:
> > Given that haproxy's main target is HTTP and that these days it often
> > comes with SSL (and it doesn't seem like it's going to revert soon),
> > I was wondering if it
Willy,
Am 05.01.21 um 17:17 schrieb Willy Tarreau:
Looks good to me in general. However for this one it would probably be
sufficient to run it on schedule once a day / week or so. The contrib
stuff is not that important.
>>>
>>> I'm ok with running them on push.
>
> Does this
Rephrase the message to no longer talk about something that "is no longer
supported", but about what actually *is* supported.
Adjustments include:
- Removal of rare targets to make it easier to find the proper one.
- Reformatting to be easier to read (more newlines)
- Explanation of common
On Sat, Jan 02, 2021 at 10:47:16PM +0100, Tim Duesterhus wrote:
> This variable is only needed deeply nested in a single location and clang's
> static analyzer complains about a dead initialization. Reduce the scope to
> satisfy clang and the human that reads the function.
On Sat, Jan 02, 2021
On Tue, Jan 05, 2021 at 11:14:58AM +0100, William Dauchy wrote:
> there was an extra `s` added to the `var_check_arg` function
Merged, thank you William.
Willy
we can try to set up a filter "build only if contrib folder was changed".
not sure such a filter exists natively in github actions
вт, 5 янв. 2021 г. в 21:45, Willy Tarreau :
> On Tue, Jan 05, 2021 at 05:36:30PM +0100, Tim Düsterhus wrote:
> (...)
> > The patch in this state is okay for me, you
Hi,
This is a friendly bot that watches fixes pending for the next haproxy-stable
release! One such e-mail is sent periodically once patches are waiting in the
last maintenance branch, and an ideal release date is computed based on the
severity of these fixes and their merge date. Responses
Dear list!
Author: Peter Skarpetis
Number of patches: 1
This is an automated relay of the Github pull request:
Fixed null pointer dereference in srv_cleanup_connections()
Patch title(s):
Fixed null pointer dereference in srv_cleanup_connections()
Link:
On Mon, Jan 04, 2021 at 12:58:25AM +0100, Tim Duesterhus wrote:
> I am adding Thayne as CC as it was your commit that uncovered the issue and
> the
> crash happened in a function you wrote. Maybe you might want to add some
> additional checks somewhere?
Oops, my bad. I actually meant to put a
30 matches
Mail list logo
