Bussiness inquiry[Backlink Expert]
*Hey,* *Are you want to promote your websites or want on google,no need for further search.here you will get google news sites guest posts with do/follow backlinks. for getting the first position,y*Bussiness Inquiry [BackLinks Expert]*ou* *need to get high/authority guest posts with do/ follow backlinks. google news approved sites is trusted by google. getting top-quality backlinks from google's trusted sites by google. getting top-quality publish high DA guest posts on the 50-90 websites with a do-follow backlink.the backlink would be permanent and it will be indexed in google let me know if I have to wait for your response.* WEBSITES DA DRTRAFFIC tamaracamerablog.com 66 47 2610 stylevore.com 62 67 1086 freegameempire.com 4732 23 *Best Regards.*
Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP
On Wed, May 08, 2024 at 01:19:22PM +, Dorian Craps wrote: > first of all, thank you for your interest. > > I already made a version with an option to enable MPTCP > -https://github.com/CrapsDorian/haproxy/pull/1 > > I'm working on a new version with "mptcp@address" as Willy requested. OK, thank you Dorian. I'm sorry not to have more time to assign to review your work at the moment, it's really a matter of bad timing :-/ Willy
RE: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP
first of all, thank you for your interest. I already made a version with an option to enable MPTCP -https://github.com/CrapsDorian/haproxy/pull/1 I'm working on a new version with "mptcp@address" as Willy requested. Dorian
[PATCH v2] MINOR: config: rhttp: Don't require SSL when attach-srv name parsing
An attach-srv config line usually looks like this:
tcp-request session attach-srv be/srv name ssl_c_s_dn(CN)
while a rhttp server line usually looks like this:
server srv rhttp@ sni req.hdr(host)
The server sni argument is used as a key for looking up connection in the
connection pool. The attach-srv name argument is used as a key for
inserting connections into the pool. For it to work correctly they must
match. There was a check that either both the attach-srv and server
provide that key or neither does.
It also checked that SSL and SNI was activated on the server. This is too
strict. This patch removes that requirement. Now you can pass arbitrary
expressions as the name expression.
With this patch we also produce a more helpful and specific error message.
I'm doing this as I want to use `fc_pp_unique_id` as the name.
Arguably it would be easier to understand if instead of using `name` and
`sni` for `attach-srv` and `server` rules it used the same term in both
places - like "conn-pool-key" or something. That would make it clear that
the two must match. But it's too late to change that now.
---
src/tcp_act.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/src/tcp_act.c b/src/tcp_act.c
index a88fab4af..cef2e50d3 100644
--- a/src/tcp_act.c
+++ b/src/tcp_act.c
@@ -520,10 +520,16 @@ static int tcp_check_attach_srv(struct act_rule *rule,
struct proxy *px, char **
return 0;
}
- if ((rule->arg.attach_srv.name && (!srv->use_ssl || !srv->sni_expr)) ||
- (!rule->arg.attach_srv.name && srv->use_ssl && srv->sni_expr)) {
- memprintf(err, "attach-srv rule: connection will never be used;
either specify name argument in conjunction with defined SSL SNI on targeted
server or none of these");
- return 0;
+ if (rule->arg.attach_srv.name) {
+ if (!srv->sni_expr) {
+ memprintf(err, "attach-srv rule has a name argument
while server '%s/%s' does not have an sni argument; either add a sni argument
to the server or remove the name argument from this attach-srv rule",
ist0(be_name), ist0(sv_name));
+ return 0;
+ }
+ } else {
+ if (srv->sni_expr) {
+ memprintf(err, "attach-srv rule has no name argument
while server '%s/%s' has an sni argument; either add a name argument to the
attach-srv rule or remove the sni argument from the server", ist0(be_name),
ist0(sv_name));
+ return 0;
+ }
}
rule->arg.attach_srv.srv = srv;
--
2.34.1
Re: [PATCH] MINOR: config: rhttp: Downgrade error on attach-srv name parsing
On Thu, Apr 25, 2024, at 2:07 PM, Amaury Denoyelle wrote:
> Sorry for the delay. We have rediscussed this issue this morning and
> here is my answer on your patch.
Sorry for the even larger delay in responding :). Thanks for looking at this.
> It is definitely legitimate to want to be able to use reverse HTTP
> without SSL on the server line. However, the way that haproxy currently
> uses idle connection is that at least the SNI parameter alone must be
> set to match the name parameter of the corresponding attach-srv rule. If
> this is not the case, the connection will never be reused.
>
> But in fact, when rereading haproxy code this morning, we found that it
> is valid to have SNI parameter set even if SSL is not active, and this
> will produce the desired effect. We are definitely okay with merging an
> adjusted version of your patch for the moment, see my remarks below.
> However, using SNI on a server line without SSL is something tricky.
> Thus we plan to add a new keyword to replace it when SSL is not used to
> have the same effect. When this will be done, you should update your
> configuration to use it.
>
> On Fri, Apr 12, 2024 at 02:29:30PM +0100, William Manley wrote:
> > An attach-srv config line usually looks like this:
> > tcp-request session attach-srv be/srv name ssl_c_s_dn(CN)
> > The name is a key that is used when looking up connections in the
> > connection pool. Without this patch you'd get an error if you passed
> > anything other than "ssl_c_s_dn(CN)" as the name expression. Now you can
> > pass arbitrary expressions and it will just warn you if you aren't
> > producing a configuration that is RFC compliant.
> > I'm doing this as I want to use `fc_pp_unique_id` as the name.
>
> I'm not 100% okay with your description here. The current code condition
> does not check that "ssl_c_s_dn(CN)" is used as expression, but rather
> that if name is defined for an attach-srv rule, the targetted server
> must have both SSL and SNI activated. I think this paragraph should be
> reworded.
I'll fix this.
> > ---
> > src/tcp_act.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> > diff --git a/src/tcp_act.c b/src/tcp_act.c
> > index a88fab4af..4d2a56c67 100644
> > --- a/src/tcp_act.c
> > +++ b/src/tcp_act.c
> > @@ -522,8 +522,7 @@ static int tcp_check_attach_srv(struct act_rule *rule,
> > struct proxy *px, char **
> >
> > if ((rule->arg.attach_srv.name && (!srv->use_ssl || !srv->sni_expr)) ||
> > (!rule->arg.attach_srv.name && srv->use_ssl && srv->sni_expr)) {
> > - memprintf(err, "attach-srv rule: connection will never be used; either
> > specify name argument in conjunction with defined SSL SNI on targeted
> > server or none of these");
> > - return 0;
> > + ha_warning("attach-srv rule: connection may never be used; usually name
> > argument is defined SSL SNI on targeted server or none of these");
> > }
> >
> > rule->arg.attach_srv.srv = srv;
> > --
> > 2.34.1
> >
>
> I think an alternative patch may be more desirable here. We could update
> the condition with the following statement without removing the fatal
> error :
>
> > if ((rule->arg.attach_srv.name && !srv->sni_expr) ||
> > (!rule->arg.attach_srv.name && srv->sni_expr)) {
>
> This reflects the current mandatory usage of reverse-http : if name is
> used on attach-srv, sni keyword must be specified on the server line.
I agree. Did you see my replacement patch "MINOR: config: rhttp: Don't require
SSL when attach-srv name parsing"
https://www.mail-archive.com/haproxy@formilux.org/msg44826.html . It
implements this general idea, but with a nice specific error message depending
on whether sni or name is missing.
That replacement patch still needs the commit message corrected as you remarked
above, so I'll send a v2 of that patch.
Thanks
Will
---
William Manley
Stb-tester.com
Stb-tester.com Ltd is a company registered in England and Wales.
Registered number: 08800454. Registered office: 13B The Vale,
London, W3 7SH, United Kingdom (This is not a remittance address.)
Faktoring
Dzień dobry, rozważali Państwo wybór finansowania, które spełni potrzeby firmy, zapewniając natychmiastowy dostęp do gotówki, bez zbędnych przestojów? Przygotowaliśmy rozwiązania faktoringowe dopasowane do Państwa branży i wielkości firmy, dzięki którym, nie muszą Państwo martwić się o niewypłacalność kontrahentów, ponieważ transakcje są zabezpieczone i posiadają gwarancję spłaty. Chcą Państwo przeanalizować dostępne opcje? Pozdrawiam Bartosz Rudnicki
