hese are required if you support the %[...]
syntax, as in:
http-request set-header foo %[bar]
With %[bar] being the log-format string.
I suggest waiting for an authoritative answer before adjusting anything,
though. This is just a guess based off the comments for the .lfs_file
member of the conf struct. :-)
Best regards
Tim Düsterhus
es the package
lists so that they reflect the most recent state.
Best regards
Tim Düsterhus
y
difference is whether warnings fail the build. It does not make sense to
not fail a few of them when the cause is the same.
Any build warnings should be treated as an error during development and
then either fixed or silenced.
Best regards
Tim Düsterhus
Willy,
Am 21.11.20 um 18:49 schrieb Willy Tarreau:
> On Sat, Nov 21, 2020 at 06:46:46PM +0100, Tim Düsterhus wrote:
>>> 2) make DEBUG_STRICT=1 default and only option
>>
>> This is what I did. Anything crashing by using DEBUG_STRICT is a bug by
>> definition (compare
the
build option? I understood the "default and only option" as "in CI only".
Willy also requested to mimic the previous behavior, thus I'll just add
that build as a scheduled build when I get around to it.
Best regards
Tim Düsterhus
Julien,
Am 22.11.20 um 15:24 schrieb Julien Pivotto:
> Here you go.
>
It looks like you sent the same patch again.
Best regards
Tim Düsterhus
ctually had issues it would be helpful if
you would put a reproducer into the commit message.
Best regards
Tim Düsterhus
action() instead of initializing
> the list (patch attached).
>From my point of view: I like that version better. It would have been
the solution I would have taken as well.
The patch should probably be BUG/MEDIUM instead of BUG/MINOR, though.
Best regards
Tim Düsterhus
I did not notice that it was different names there :-/
Willy: These two patches look good to me.
Thanks.
Tim Düsterhus
proxy/commit/1e237d037b3a45ec92d1dfa80dfd2c6bd7fc3af9.
>From the wording in commit message I would assume that it's not a third
party contribution. Did someone of you change machines without a proper
git setup?
Best regards
Tim Düsterhus
ress per customer.
Best regards
Tim Düsterhus
tual issue instead of suppressing the warning?
In fact I believe that this line is incorrectly intended:
https://github.com/haproxy/haproxy/blob/a4009cd6103a92752db27c3a85051c6adcc832c1/include/import/plock.h#L236
Best regards
Tim Düsterhus
89bb81a380R228)
> I'd say it is friendly mood not to push people to comply formatting (who
> cares of indentation ?)
I do when it's misleading.
Best regards
Tim Düsterhus
4) It would require contributors to set up that autoformatter (in the
correct version, with the correct config, etc.), creating work for a
small benefit.
Best regards
Tim Düsterhus
> I'm partial to failing the build (in CI) to avoid using further
> electricity if the first step (s
/ip6range/ip6range.c:
https://github.com/deltablot/haproxy/commit/878ba41e4742b39034686d2b6feb3c561edeb72a#diff-f99a0be674dc22ec08274e8ae4e68be49a16d905afdeb918d31779898ba08ba9L74-R84
It definitely does not help readability :-)
Best regards
Tim Düsterhus
PS: Prefer replying inline instead of top-postin
>
I'm not sure I understand the question correctly, but I assume you mean
the highlighting due to me directly linking to the lines?
You can select a range of line numbers by clicking the first line,
holding Shift and clicking the second line. The URL bar will
automatically updated to link to th
d. We're primarily interested in that it
compiles. No need to retest all the other stuff again.
> do we want to expand build matrix or to add pcre2 to some existing build ?
>
Expand the matrix, please.
Best regards
Tim Düsterhus
to the compliance
and codespell ones?
Best regards
Tim Düsterhus
Willy,
Am 21.12.20 um 12:22 schrieb Willy Tarreau:
> Just my two cents, I'm interested in anyone's opinion or suggestion here.
Your proposal sounds good to me.
Best regards
Tim Düsterhus
-2020. Q4 is almost over. Is this on your radar? It probably makes
sense to:
- do a final 1.6 release, and
- at the same time move 1.8 to "critical fixes" only.
Best regards
Tim Düsterhus
nto that report:
https://github.com/haproxy/haproxy/issues/1010, but then I got
distracted by this indentation issue.
Best regards
Tim Düsterhus
7;))
> + ha_bit_set(i, url_encode_map);
> + }
> + ret = encode_string(trash->area, trash->area + trash->size, '%',
> + url_encode_map, smp->data.u.str.area);
> + if (ret == NULL || *ret != '\0')
> + return 0;
> + trash->data = strlen(trash->area);
> + smp->data.u.str = *trash;
> + return 1;
> +}
> +
Best regards
Tim Düsterhus
g to get any new minutes any time soon. On the other
hand having that .travis.yml is not going to cost us anything, so I
guess we can just keep it.
Willy: This patch is good, please take it.
Best regards
Tim Düsterhus
e also this recent discussion on Hacker News:
https://news.ycombinator.com/item?id=25338983
Best regards
Tim Düsterhus
d in early 2019 (see
https://en.wikipedia.org/wiki/Travis_CI#Company) and they also reported
that many users would abuse Travis CI builds to mine Bitcoins until the
job timed out after 50 minutes. You really can't have nice things.
> Removal patch applied by the way.
Thanks!
Best regards
Tim Düsterhus
newlines to `apt-get install`.
d) Move the `if` out of bash into the YML definition.
e) Use `-fsSL` flags for curl to make sure it catches all errors and
works for redirects.
Can you please check that the changes did not break anything? I attached
the updated patch.
Best regards
Tim Düs
ocs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#schedule)
any workflows that are triggered by a schedule will run on the default
branch (i.e. `master`). So I don't think we need to change anything for
that.
Best regards
Tim Düsterhus
From 63ed5405668799f45b6
>
I don't think so. But my understanding is that the job won't run on pull
requests and with the new `job` level `if` I added in response to your
other mail it should automatically be skipped on forks. So there is no
useless running in forks and it will not leak the token either.
Best regards
Tim Düsterhus
ent the job from running in forks. And for our repository it
will effectively always have the token.
Best regards
Tim Düsterhus
messed up the direct link: It's at "Settings" -> "Secrets" ->
"New Repository Secret")
I don't have it. Ilya will need to send it to you unless you happen to
have it somewhere in your email archives.
Best regards
Tim Düsterhus
Yes, I agree. Especially since adding new known encodings is easy to do
(add a bit, add logic to add that bit) and can easily be backported to
stable branches.
Best regards
Tim Düsterhus
accept-encoding specifically). And
> considering that we probably don't want to parse the content-encoding
> all the time, responses with an unknown encoding would only be
> considered uncacheable when they have a vary, and would be cached when
> they don't. I'm totally fin
.com/haproxy/haproxy/runs/1619717275?check_suite_focus=true
I'm a bit confused by the last line "Coverity Scan upload failed: Build
successfully submitted..".
It says both "failed" and "successfully". I'm not sure if that is
correct but Ilya will hopefully be able to tell us if it worked.
Best regards
Tim Düsterhus
tdated since the refactoring
of the repository. As an example the ebtree stuff now is in
include/import/eb*tree.h. It probably should be updated.
Best regards
Tim Düsterhus
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
sufficient to run it on schedule once a day / week or so. The contrib
stuff is not that important.
Best regards
Tim Düsterhus
date your message accordingly),
> the unchecked strdup() were in fact added by commit 99c453df in 2.2-dev9 so
> the backport will only be for 2.2 and not 2.1.
>
Oh, indeed. Thanks.
Best regards
Tim Düsterhus
; and "out of memory error", so this patch
was not good. However all in all it's very inconsistent.
I've opened https://github.com/haproxy/haproxy/issues/1025 to not forget
this and will send a new patch once I get around to it.
Thanks
Tim Düsterhus
pile themselves can usually be expected to read
the `INSTALL` file.
I would be fine with a warning if `USE_OPENSSL` is not explicitly
provided, though.
Best regards
Tim Düsterhus
ufficient for the less important contrib/ stuff,
which Ilya declined.
The patch in this state is okay for me, you can take it.
Best regards
Tim Düsterhus
*sample, int slen, const char *word, int
> wlen)
> {
This fix is incorrect. It should be 'to', not 'or'. Same in ev_poll, and
ev_select.
Best regards
Tim Düsterhus
knowledge
unknown encodings still use the crc32. The hash is not used for known
encodings, though.
Best regards
Tim Düsterhus
he free space at the beginning of the message. Once this one is
> used, the
Didn't check all in detail, but that one is most likely not a typo.
`iff` means `if and only if`.
Best regards
Tim Düsterhus
ot;, or to add iff to the list of ignored words?
I don't have a strong opinion either way.
Best regards
Tim Düsterhus
seeing.
I'm just wondering if it technically would be necessary to remove the
server from the tree or not?
Best regards
Tim Düsterhus
ion will not be lost.
The current list of feature requests can be found here:
https://github.com/haproxy/haproxy/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+feature%22
Best regards
Tim Düsterhus
tures. However one could argue that an
> issue without a status label would imply it's in progress, which would
> then suggest that we'd need to add a "status: triage" to new features
> just like new bugs.
I'm not sure that's necessary. For features there IMO only three states:
- Implemented: Closed + Fixed.
- Not Planned: Closed + No Label.
- Maybe Planned: Open.
Best regards
Tim Düsterhus
Hi List,
Ilya,
as a heads up: It appears that recent VTest changes broke support for
macOS. I filed an issue upstream: https://github.com/vtest/VTest/issues/26
Best regards
Tim Düsterhus
s
'backport+' instead of 'backports+' (missing 's').
Best regards
Tim Düsterhus
egards
Tim Düsterhus
Bertrand,
Am 17.01.21 um 20:19 schrieb Bertrand Jacquin:
> On Sunday, January 17 2021 at 20:02:47 +0100, Tim Düsterhus wrote:
>> Bertrand,
>>
>> Am 17.01.21 um 19:58 schrieb Bertrand Jacquin:
>>> This is a pretty lame commit in a attempt to use a common wording
ion does not match
> its behavior anymore either.
Indeed. I adjusted that on v2.
Best regards
Tim Düsterhus
/tag
I don't think introducing additional complexity by that variable is
better than adding + reverting a patch that hardcodes a known good commit.
I fact I just went ahead and attached a patch.
Best regards
Tim Düsterhus
From ef80933eca0c8cf83e119cd9b3e96a5dcfd776e6 Mon Sep 17 00:00:00 2001
Fr
, so I just put you in CC here for you to
take a look.
Best regards
Tim Düsterhus
he repository specific git
config should "fix" it for any future patches, while not changing
anything about other projects.
Best regards
Tim Düsterhus
it is fixed.
> I'm taking your patch, thanks!
And now the repository is back to green. Perfect.
Best regards
Tim Düsterhus
ub.com/haproxy/haproxy/issues/680#issuecomment-764475902
Best regards
Tim Düsterhus
t
do this.
5. The test was just to make sure it behaves somewhat sanely (i.e. does
not send entirely wrong information) for HTTP traffic. My intention was
not to test that Keep-Alive is possible.
So: Please go ahead with your modification, change the test to make sure
keep-alive does not happen and adjust the documentation as necessary.
Best regards
Tim Düsterhus
is guarded by the #if. As such
sample_conv_secure_memcmp guarantees the constant time comparison
(independent of the library support). It just might be that the function
might not exist.
Best regards
Tim Düsterhus
tations. IMO If
users actually need secure_memcmp in HAProxy they should upgrade their
OpenSSL.
Best regards
Tim Düsterhus
Bertrand,
Am 22.01.21 um 00:58 schrieb Tim Düsterhus:
> Am 22.01.21 um 00:45 schrieb Bertrand Jacquin:
>>> The strcmp converter is not binary safe. It uses strncmp internally.
>>
>> It is not indeed, what do you think of improving current related strcmp
>> documenta
constantly having to define extra
> "DEBUG_xxx" stuff to shut it up ? Maybe there's even something for
> the unreachable case by the way.
Ilya will need to answer this.
Best regards
Tim Düsterhus
olla/haproxy/runs/1786232933?check_suite_focus=true
You can see that the 'Run Coverity Scan' step works and that it includes
the necessary defines.
Ilya: Can you please test the patch with Coverity in your fork?
Best regards
Tim Düsterhus
>From 2ea3507f42c1c62b50f40cbb8eeaed3c62db4b13
https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#hard-stop-after
Best regards
Tim Düsterhus
Willy,
Am 11.02.21 um 19:35 schrieb Илья Шипицин:
> attached patch fix freebsd builds.
This one looks good to me. Please take it.
Best regards
Tim Düsterhus
for the older ones. Similarly
it would have allowed me to already remove the Lua script I was running
in favor of `http-request return`.
>- streq(a,b): compare two strings (should be careful, maybe it would
> be better to rethink about this for expressions later):
I think this one is useful for the examples you gave.
Best regards
Tim Düsterhus
now that it will modify ptr, but I'm pretty sure
> that more often than not the second form may be used by thinking about
> "free()". So I didn't merge anything and am interested in developers'
> opinions on this and even alternate proposals.
Use `ha_free(&ptr)`, because we already have `istfree(&ist)`.
Best regards
Tim Düsterhus
me for C
files even without this. Even better if this also improves the regular
diff output for you!
git includes a few additional userdiff drivers for other programming
languages: https://github.com/git/git/blob/master/userdiff.c.
I'm not seeing anything obviously useful, but maybe have a look
Willy,
Am 20.02.21 um 21:28 schrieb Willy Tarreau:
> Now applied, thank you!
I'm not seeing anything, yet. Just to make sure: Did you just forget to
'git push'?
Best regards
Tim Düsterhus
d TTLs in
> the SRV records.
I believe this might be a duplicate of this existing issue:
https://github.com/haproxy/haproxy/issues/1160
Best regards
Tim Düsterhus
the authority and unique ID bothered me
endlessly and was easy enough to fix :-)
Best regards
Tim Düsterhus
for
it. And I also believe you wanted to put 1.8 to "critical only" as well.
Best regards
Tim Düsterhus
Willy,
Am 19.03.21 um 18:29 schrieb Willy Tarreau:
> [...] I know Christopher will harrass me if I
> forget anyway :-)
Be assured, I will as well :-)
Best regards
Tim Düsterhus
Willy,
Am 19.03.21 um 18:52 schrieb Илья Шипицин:
> let us update libressl to 3.2.5 and revert previously disabled tls session
> resumption in reg-test
>
Both of these look good to me.
Best regards
Tim Düsterhus
te a lot!
>
After the update haproxy.org shows a stray '>' above the table. This is
caused by an additional '>' after the '' element for the 1.8 row.
You might want to remove that.
Best regards
Tim Düsterhus
n cause a rebuild of the 'haproxy' image.
For the images that contain a username (e.g. timwolla/haproxy) the
authors are responsible to trigger a rebuild.
Best regards
Tim Düsterhus
[1] https://github.com/docker-library/haproxy/
[2] https://github.com/docker-library/official-images/
Paul,
On 3/25/21 7:31 PM, Paul Lockaby wrote:
> Thanks for all of the responses! So the image version number for HAProxy
> stays the same but the hash will update?
>
Yes exactly.
Best regards
Tim Düsterhus
est
directed here: https://github.com/docker-library/official-images/
However I don't expect this to be implemented. It seems to introduce
much work for very little benefit and might prevent users that
accidentally use these tags without understanding them from receiving
security fixes. Tianon
m/haproxy/haproxy/issues/760#issuecomment-805280316?
While the issue for Docker is fixed by manually applying the patch [1]
the current official release fails the build for musl.
Best regards
Tim Düsterhus
[1]
https://github.com/docker-library/haproxy/commit/42989bf9ab08e05e7333261ce62fff00d0dcb08a
char *in, size_t ilen, char *out, size_t olen) {
+ char conv[ilen+2];
This looks like a remotely triggerable stack overflow.
[...]
/* Converts the lower 30 bits of an integer to a 5-char base64 string. The
* caller is responsible for ensuring that the output buffer can accept 6 bytes
Best regards
Tim Düsterhus
not searching for a
fetch. You want a converter, because you are converting an existing
sample. I suggest you take a look at the "digest" converter. You can
find it in sample.c.
Best regards
Tim Düsterhus
se it is not really
actionable.
I'd preferred if you would not have taken the patch yet. A follow-up
feels ugly and writing a good commit message is hard :-)
Patch atteched.
Best regards
Tim Düsterhus
>From e0bfbc39ca443ca07dc4676b78ea56d131adb311 Mon Sep 17 00:00:00 2001
From: Tim D
Willy,
On 4/3/21 8:39 PM, Tim Duesterhus wrote:
Nothing is being modified there, so this can be `const`.
As you've taken my other series and not this one, consider this to be a
push :-)
Best regards
Tim Düsterhus
_kw_list sample_conv_kws = {ILH,
{
{ "cut_crlf", sample_conv_cut_crlf, 0, NULL, SMP_T_STR,
SMP_T_STR },
{ "ltrim",sample_conv_ltrim,ARG1(1,STR), NULL, SMP_T_STR,
SMP_T_STR },
{ "rtrim",sample_conv_rtrim,ARG1(1,STR), NULL, SMP_T_STR,
SMP_T_STR },
+
+ { "json_string", sample_conv_json_string, ARG1(1,STR),
sample_check_json_string , SMP_T_STR, SMP_USE_CONST },
+
{ NULL, NULL, 0, 0, 0 },
}};
--
2.25.1
Best regards
Tim Düsterhus
;printf' while debugging my code.
But it is going to be removed after I finish debugging. The parts I
touch are usually not that complex or deep in the internals that such
output would be useful enough in case issues arise.
+ { "json_string", sample_conv_json_string, ARG1(1,STR),
sample_check_json_string , SMP_T_STR, SMP_USE_CONST },
While testing something I also just notice that SMP_USE_CONST is
incorrect here. I cannot apply e.g. the sha1 converter to the output of
json_string.
Best regards
Tim Düsterhus
/* These type are not const. */
break;
case SMP_T_STR:
```
I would to the conversation from double to int like "smp->data.u.sint =
(long long int ) double_val;"
is this efficient. I haven't done this for a long time so I would like
to have a "2nd eye pair" on this.
I'd probably return a double as a string instead. At least that doesn't
destroy information.
Best regards
Tim Düsterhus
rash;
+ smp->data.type = SMP_T_STR;
+ }
+ } else {
+ trash->data = rc;
+ smp->data.u.str = *trash;
+ smp->data.type = SMP_T_STR;
+ }
+
+ return 1;
+}
+
+
/****/
/* All supported sample fetch functions must be declared here */
//
@@ -4165,6 +4257,8 @@ static struct sample_conv_kw_list sample_conv_kws = {ILH,
{
{ "cut_crlf", sample_conv_cut_crlf, 0, NULL, SMP_T_STR,
SMP_T_STR },
{ "ltrim",sample_conv_ltrim,ARG1(1,STR), NULL, SMP_T_STR,
SMP_T_STR },
{ "rtrim",sample_conv_rtrim,ARG1(1,STR), NULL, SMP_T_STR,
SMP_T_STR },
+{ "json_string", sample_conv_json_query, ARG2(1,STR,STR),
sample_check_json_query , SMP_T_STR, SMP_T_ANY },
a) Incorrect indentation.
b) The converter still is called "json_string". You forgot to update the
name.
+
{ NULL, NULL, 0, 0, 0 },
}};
--
2.25.1
Best regards
Tim Düsterhus
ion? I remember something about these
buffers being reused, accidentally destroying the contained information
if one is not careful.
Best regards
Tim Düsterhus
I will probably merge the two
patches and change the default once the general approach is approved :-)
Best regards
Tim Düsterhus
tp-request normalize-uri action will pass a trash buffer
pointer into the function, that's why I found the name somewhat fitting.
But the exact method signature is up for discussion anyway (see my other
email).
Best regards
Tim Düsterhus
decode or something
like that would be misleading.
Best regards
Tim Düsterhus
Aleks,
On 4/14/21 1:19 PM, Aleksandar Lazic wrote:
From 46ddac8379324b645c662e19de39d5de4ac74a77 Mon Sep 17 00:00:00 2001
From: Aleksandar Lazic
Date: Wed, 14 Apr 2021 13:11:26 +0200
Subject: [PATCH 2/2] MINOR: sample: converter: Add json_query converter
With the json_query can a JSON value be
Willy,
On 4/14/21 7:00 PM, Илья Шипицин wrote:
something changed in freebsd packaging. we now need to install pcre
directly.
This one looks good to me.
Best regards
Tim Düsterhus
:-)
Aleks: Thanks for quickly addressing my feedback, even if you might
think I was overly pedantic. The final version looks pretty good to me,
my CLEANUP really is meant to be a final polishing!
Best regards
Tim Düsterhus
>From 1af53a6e73e75f48793720017fe07d0f57e8c74a Mon Sep 17 00:00:00 20
complain myself afterwards as well :-)
As a heads up I'll definitely add a few more converters (most notably
the percent decoder is missing) and maybe I'll rename the existing ones
in the configuration for consistency once I finish this up.
So: It should definitely considered *EXPERIMENTAL* f
. Most notably not being allowed to `for
(size_t i = 0; ...; ...)` is bothering me quite a bit.
But who am I to complain? Updated patches attached. I left the 'trash'
one as-is, because that one really is a common pattern. I hope I did not
miss anything else :-)
Best regards
Tim Düs
e configuration syntax to be
stable enough for a 2.4. I'll leave the final decision regarding that up
to you, though. Especially since 2.4 is going to be an LTS.
Best regards
Tim Düsterhus
>From 02a0a18f3739dc9b0ed6297c76d6742f8f59c1eb Mon Sep 17 00:00:00 2001
From: Tim Duesterhus
Date: Sa
y should not be applied to the query
string! The actions hide this type of detail from the user which I
consider to be a good thing.
Best regards
Tim Düsterhus
t few normalizers that I
planned to add and I'm looking forward to feedback from the users :-)
Best regards
Tim Düsterhus
s
as well. We may do that during 2.5-dev and possibly backport them
if there is some demand.
Best regards
Tim Düsterhus
Willy,
On 4/16/21 8:30 PM, Tim Düsterhus wrote:
But who am I to complain? Updated patches attached. I left the 'trash'
one as-is, because that one really is a common pattern. I hope I did not
miss anything else :-)
I believe you might've missed my updated patches.
Best regards
Tim Düsterhus
401 - 500 of 868 matches
Mail list logo
