)
but that's for them to request if and when they judge it necessary.
Tristan
PS: I see you already do, but for others reading this, you definitely
want 2.7.7 or a 2.8 base after 7b516d3732aab5999fc8f4a3037a4317d35d3618
if you're playing with H3/QUIC. The recent few commits make a
significant difference in compatibility.
It switched for no reason
one day. Even trying HTTPS/SVCB DNS records did nothing for us until it
"magically" decided to use H3.
Tristan
ld give the upgrade request priority), which
ends up with the same outcome as the Alt-Svc solution if it works
Of course it'd be many times better to be able to just trigger a GOAWAY
instead, but it was fun to think about more "creative" options, so here
they are.
Tristan
to HAProxy.
Interesting problem either way!
Cheers,
Tristan
ed seems (to me) like it's coming out of nowhere
Tristan
hink that
at first glance
bool,iif(str,str): str
which I didn't mention before might possibly be the best choice?
I do quite like that
Best regards, and thanks for the bike-shedding exercise :D
Tristan
y/issues/1808#issuecomment-1230660870 :)
Tristan
must-staple with it?
(Probably not super relevant, but this is with HAProxy 2.8.1 and QuicTLS
1.1.1t)
Thanks in advance,
Tristan
d instead, it would not be that unreasonable for HAProxy to
adopt the patch either...
Between a rock and a hard place,
Tristan
can't help wonder if an
opt-in mechanism similar to the server state file would make sense for it?
Either way, it all worked flawlessly within these constraints after
putting the brackets, so that's great. Thanks.
Tristan
On 07/07/2023 16:34, Willy Tarreau wrote:
On Fri, Jul 07, 2023 at 03:06:52PM +, Tristan wrote:
The ocsp-update option should be between brackets
/etc/haproxy/ssl/mangadex.dev.pem [ocsp-update on] mangadex.dev
*.mangadex.dev
Oh that makes more sense indeed; should have guessed so since
oute. In such a case, you can either create the appropriate
route or set the "httpclient.resolvers.prefer ipv4" option in the global
section.
Hopefully fixes your issue, as it did when I had the same issue.
Tristan
ps: I hope this message doesn't get sent as html, since I'm writing
this variant for QUIC not be much easier,
from my point of view.
Now as for complexity, I can only agree that I hope it will be simpler
for everyone, implementers as well as users... since easiness of use
really was not a strong point of WS...
Tristan
of
request affected to see if I can reproduce it on our nodes.
Regards,
Tristan
t reliable
metric… Something like the NEL spec is the more scientific approach to this by
far https://web.dev/network-error-logging/
Hopefully in the coming days I find time to compile this long mail in a
slightly more organized wiki article with snippets etc, but it will do in the
meantime
Trista
ver how feasible it will
realistically be from dpapi’s perspective to add that to its remit.
That said I’d definitely be very interested as well. As much as handcrafted
configurations are nice, one quickly reaches their maintainability limits. And
if we’re to stop abusing DNS again and again, proper service discovery is the
way.
Tristan
frames).
Finally I'll note that I don't currently have access to a good way to
test how much it affects HAProxy. And maybe it doesn't due to some
peculiar implementation detail. But that would be good to know.
Regards,
Tristan
as nicely as it could when it comes to
integrating it with other software.
Tristan
eive…
Though most seem to be either L4 or non-HTTP L7.
> As Tristan mentioned, lowering tune.h2.be.max-concurrent-streams may
> also slow them down but it will also slow down some sites with many
> objects (think shops with many images). For a long time the high
> parallelism of H2 was
at while it's great to have it, it's still a little bit
awkward in practice, because of the number of fields to check. As in
proper validation of iss, aud, exp, and keys turns out to be very
verbose in the haproxy configuration.
Not saying it's a bad thing in any way, mind you. And it's great to have
it. But it's not quite the same as a theoretical
http-request filter oauth2
https://auth.foo.bar/.well-known/openid-configuration
Tristan
By default, messages printed from LUA log functions are sent both to
the configured log target and additionally to stderr (in most cases).
This introduces tune.lua.also-log-to-stderr for disabling that
second copy of the message being sent to stderr.
Addresses https://github.com/haproxy/haproxy/i
Hi Willy,
On 18/10/2023 07:47, Willy Tarreau wrote:
Hi Tristan,
...
I'm fine with the general approach, but I'm having two comments:
- using the word "also" in the option name is really not welcome
("tune.lua.also-log-to-stderr"), and actually mo
said, I'd definitely do that in a follow-up patch.
Tristan
only thing to avoid is to send multiple
series for review before getting feedback, that's extremely confusing,
but fortunately this almost never happens here.
Ok. Probably will reply to first message of this thread with 2 diff
files (one for 2.8 and one for 2.9 to account for default config
difference) then.
Tristan
E_LOG))
&& (!LIST_ISEMPTY(&px->loggers)))
|
^~
include/haproxy/list.h:102:28: note: in definition of macro ‘LIST_ISEMPTY’
102 | #define LIST_ISEMPTY(lh) ((lh)->n == (lh))
|^~
Which would make sense if struct proxy had n
On 20/10/2023 15:30, Tristan wrote:
ie in this snippet (hlua.c:1387):
static inline void hlua_sendlog(struct proxy *px, ...)
{
...
if (... && (!LIST_ISEMPTY(&px->loggers)))
return;
has the following results:
- locally from source => compiles happily
-
I'm be happy to write some if yes, but I know regtests runtime is a
concern and it'd require a bit of test infra work to make capturing
stderr output, so I just want to be sure it is desirable before :-)
Regards,
Tristan
From 45e6f271404d20479284fc3e0e1f7448e260e016 Mon Sep 17 00:00:00 2
Following up on Aurélien's remarks (thanks for catching my forgetting
it!), here's an additional patch to update the LUA-specific documentation.
Could be kept standalone or merged into the first patch, but to avoid
re-submitting the patchset already, here it is standalone for now.
(400k+ active sessions in a single realm). So it is
still a decent solution. I'm just not sure I'd pick it again today if I
had to choose.
Tristan
[1]: By serious, I mean intended for usage when malicious clients are
not just a theoretical threat. So with a very defensive design,
com
n on the matter, so I just picked the one I think looks nicest...
- For the regtests, if we don't want them to tee stderr to check it,
then there's little point, and chance of breaking this all is also
rather low anyway as you said, so none added
Regards,
Tristan
From 7ef333b8803c213ab1bd
plied on top of
haproxy master branch.
Oh, I thought patch commit hashes carried through when applied. Well, TIL.
Tristan
On 23/10/2023 14:38, Tristan wrote:
Thanks both for your time helping me with it :)
On 23/10/2023 14:34, Aurelien DARRAGON wrote:
Just a side note regarding the comment from the 2nd patch: it's not
useful to mention the commit ID from the previous patch given that the
effective comm
t it might not be in your build?)
Regards,
Tristan
n instead of
hard reloads, and only using the latter in limited cases 🤔
Maybe the used the « community » ingress controller (bless their maintainer,
it’s not a jab at it) which does rely more on hard reloads
Either way, sounds unlikely to be a fix for it?
Tristan
[1]: Also a bit out of top
ective ?
If I remember correctly, the baked-in directives work by *appending*, so
they’re only ok for intermediate proxies, not for edge ones.
Tristan
But yes, that works too
Tristan
n could probably give you ideas (or be partially repurposed
for non-k8s use, which I said I'd open a GH issue for ages ago, and then
forgot to do...)
As an aside, I imagine that this is roughly how cloud providers
implement their LBaaS/APIGateway solutions, as it's similar in spirit to
the cloud-init+metadata-server setup they nearly all use for VM management.
Tristan
e a failed attempt at using an operator inside a pattern list
> […]
That already sounds very helpful. I haven’t checked locally but adding an
option similar to zero-warning for diagnostics warnings could be nice on top of
it; depends on how many FPs happen in practice
Tristan
arnings, only
> 15 are caught by -dD, essentially due to "weight 0" on a server line, or
> due to a "global" section placed after another section (typically after
> a "ring" one for traces).
Funny you mention it, I’m pretty sure I’m guilty of the ring/global ordering
one.
I will check that later.
Tristan
but considering that aiming for bleeding edge
with WolfSSL is not entirely compatible with how most distros work (ie
even if it was packaged, it's likely going to be perpetually quite far
behind), what does the future look like in that regard from the distros'
side?
Thanks,
Tristan
Hi Zach,
(Replying on the ML since your reply was directly to me only)
On 08/02/2024 21:10, Zach Pearson wrote:
Thanks for the reply, Tristan, and sorry for the late reply!
To add a little more context for our haproxy setup, we currently deploy haproxy
along with a sidecar control-plane that
e the
best (besides bug reports anyway).
Either way, for now I'm waiting on OCSP support first (hi William,
Rémi); hopefully someone else figures out the best build flags by the
time that's dealt with.
Tristan
://github.com/haproxy/haproxy/issues/2479).
Since I do quite want this, I also came up with a patch for it, attached
to this email.
Marked as RFC for now because there hasn't really been a broad
discussion on the topic yet.
Thanks,
Tristan
From 24962900bd6e537cdc2fd293359d2092c93ff683 Mon Sep 17
ay
from padding
- abns2@ eventually the default, which is quite jarring I suppose
If it's easier that way, I'd prefer making it a proper bind/server
option, which allows for easier transition, and can just change default
value down the line if necessary?
Thanks,
Tristan
x27;t find better, but that
would mean declaring a failure and having to break that stuff sometime in
the future, which is always a pain.
To be honest, I don't think this is unfixable. It's just a matter of how
much code change we think is acceptable for it. If push comes to shove,
one can always add an extra field somewhere, or an extra arg in
get_addr_len, even if it'd be a little ugly.
Tristan
Hi Willy,
On 09/03/2024 16:51, Willy Tarreau wrote:
Hi Tristan,
On Sat, Mar 09, 2024 at 04:20:21PM +, Tristan wrote:
To be honest, I don't think this is unfixable. It's just a matter of how
much code change we think is acceptable for it.
I don't mind about the amount of
On 09/03/2024 18:09, Tristan wrote:
Hi Willy,
On 09/03/2024 16:51, Willy Tarreau wrote:
Hi Tristan,
On Sat, Mar 09, 2024 at 04:20:21PM +, Tristan wrote:
To be honest, I don't think this is unfixable. It's just a matter of how
much code change we think is acceptable for it.
there’s the downside of requiring an extra tool everyone might not be
deeply familiar with already, and cmake versions matter more than gmake ones so
I would worry about compatibility for distros of the GCC 4 era, but it seemed
to me like it’s reasonably proven and spread by now to consider.
Tristan
, and I'd be
interested in these if they exist somewhere, if only out of curiosity.
Regards,
Tristan
[1]: Or often essentially nonexistent, short of reading dozens of papers
off arxiv, of which the majority seem to focus on PoCs rather than
practical advice
#x27;t see the abns/abns2 split as worth it, as opposed to a
`pad { on | off }` (or similar) bind argument being added to the abns spec
Tristan
On 09/03/2024 14:02, Tristan wrote:
On 09/03/2024 18:09, Tristan wrote:
Hi Willy,
On 09/03/2024 16:51, Willy Tarreau wrote:
Hi Tristan,
On Sat, Ma
Hi Willy,
> On 9 Aug 2024, at 16:26, Willy Tarreau wrote:
> […]
> I'd be interested in opinions on some of these options:
> - deprecate duplicate server names for 3.1, requiring a global option
>to support them and drop their support for 3.3 ?
> - just drop the support of duplicate server
Hi,
I am packaging haproxy for distribution and want to pass all non-regression
test.
I do not find a fancy user test suite like a make check and so on.
Is there guideline for how executing test in tests/ directory (*.cfg,*.c) ?
Thanks for reply
52 matches
Mail list logo
