SameSite attribute for persistent session cookie

[mickael.bride]

Hello,

With Chrome 80 release in february, HAProxy persistent session cookie will not 
be working anymore for sites embedded into iframe on multiple domains.
See issue https://github.com/haproxy/haproxy/issues/361
Have you planned something to manage that point soon ?

Thank you,

Mickaël



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: [PATCH] MINOR: ssl: accept 'verify' bind option with 'set ssl cert'

[William Lallemand]

On Mon, Jan 20, 2020 at 05:33:53PM +0100, Emmanuel Hocdet wrote:
> Hi,
> 
> A last patch for today.
> 
> ++
> Manu

Good point, merged. Thanks!


-- 
William Lallemand

[PATCH] MEDIUM: dns: support for Additional section

[Baptiste]

Hi there,

For those using DNS service discovery through SRV record, you might be
aware that HAProxy is quite verbose with your DNS server: it does one SRV
query + 1 A/ per server found in the SRV response.
This patch aims at improving this behavior par using first Additional
records if available and relevant. If none found, previous behavior will
apply (on a per server basis).
This is behavior defined in RFC 2782 for DNS SRV records.

Baptiste
From a18ab5880ee04b75234eb65ca8a8be4a425d5ba6 Mon Sep 17 00:00:00 2001
From: Baptiste Assmann 
Date: Fri, 7 Jun 2019 09:40:55 +0200
Subject: [PATCH] MEDIUM: dns: use Additional records from SRV responses

Most DNS servers provide A/ records in the Additional section of a
response, which correspond to the SRV records from the Answer section:

  ;; QUESTION SECTION:
  ;_http._tcp.be1.domain.tld. IN  SRV

  ;; ANSWER SECTION:
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A1.domain.tld.
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A8.domain.tld.
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A5.domain.tld.
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A6.domain.tld.
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A4.domain.tld.
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A3.domain.tld.
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A2.domain.tld.
  _http._tcp.be1.domain.tld. 3600 IN  SRV 5 500 80 A7.domain.tld.

  ;; ADDITIONAL SECTION:
  A1.domain.tld.  3600IN  A   192.168.0.1
  A8.domain.tld.  3600IN  A   192.168.0.8
  A5.domain.tld.  3600IN  A   192.168.0.5
  A6.domain.tld.  3600IN  A   192.168.0.6
  A4.domain.tld.  3600IN  A   192.168.0.4
  A3.domain.tld.  3600IN  A   192.168.0.3
  A2.domain.tld.  3600IN  A   192.168.0.2
  A7.domain.tld.  3600IN  A   192.168.0.7

SRV record support was introduced in HAProxy 1.8 and the first design
did not take into account the records from the Additional section.
Instead, a new resolution is associated to each server with its relevant
FQDN.
This behavior generates a lot of DNS requests (1 SRV + 1 per server
associated).

This patch aims at fixing this by:
- when a DNS response is validated, we associate A/ records to
  relevant SRV ones
- set a flag on associated servers to prevent them from running a DNS
  resolution for said FADN
- update server IP address with information found in the Additional
  section

If no relevant record can be found in the Additional section, then
HAProxy will failback to running a dedicated resolution for this server,
as it used to do.
This behavior is the one described in RFC 2782.
---
 include/types/dns.h|   4 +-
 include/types/server.h |   1 +
 src/dns.c  | 216 +
 src/server.c   |   9 ++
 4 files changed, 229 insertions(+), 1 deletion(-)

diff --git a/include/types/dns.h b/include/types/dns.h
index 8347e93ab..7e592b285 100644
--- a/include/types/dns.h
+++ b/include/types/dns.h
@@ -151,6 +151,7 @@ struct dns_answer_item {
 	struct sockaddr address; /* IPv4 or IPv6, network format */
 	chartarget[DNS_MAX_NAME_SIZE+1]; /* Response data: SRV or CNAME type target */
 	time_t  last_seen;   /* When was the answer was last seen */
+	struct dns_answer_item *ar_item; /* pointer to a RRset from the additionnal section, if exists */
 	struct list list;
 };
 
@@ -158,7 +159,8 @@ struct dns_response_packet {
 	struct dns_header header;
 	struct list   query_list;
 	struct list   answer_list;
-	/* authority and additional_information ignored for now */
+	struct list   ar_list; /* additional records */
+	/* authority ignored for now */
 };
 
 /* Resolvers section and parameters. It is linked to the name servers
diff --git a/include/types/server.h b/include/types/server.h
index 842e033ad..598dfe6d8 100644
--- a/include/types/server.h
+++ b/include/types/server.h
@@ -142,6 +142,7 @@ enum srv_initaddr {
 #define SRV_F_COOKIESET0x0100/* this server has a cookie configured, so don't generate dynamic cookies */
 #define SRV_F_FASTOPEN 0x0200/* Use TCP Fast Open to connect to server */
 #define SRV_F_SOCKS4_PROXY 0x0400/* this server uses SOCKS4 proxy */
+#define SRV_F_NO_RESOLUTION 0x0800   /* disable runtime DNS resolution on this server */
 
 /* configured server options for send-proxy (server->pp_opts) */
 #define SRV_PP_V1   0x0001   /* proxy protocol version 1 */
diff --git a/src/dns.c b/src/dns.c
index 5ecb46905..eefd8d0dc 100644
--- a/src/dns.c
+++ b/src/dns.c
@@ -516,6 +516,14 @@ static void dns_check_dns_response(struct dns_resolution *res)
 	struct server  *srv;
 	struct dns_srvrq   *srvrq;
 
+	/* clean up obsolete Additional r

Re: [PATCH] BUG/MINOR: ssl: fix 3 memory leaks with set ssl cert

[William Lallemand]

On Mon, Jan 20, 2020 at 05:09:59PM +0100, Emmanuel Hocdet wrote:
> 
> Hi,
> 
> Fix memory leaks with « set ssl cert ».
> 
> ++
> Manu
> 
> 

Thanks, merged!



-- 
William Lallemand

Re: SameSite attribute for persistent session cookie

[Christopher Faulet]

Le 21/01/2020 à 09:14, mickael.br...@orange.com a écrit :

Hello,

With Chrome 80 release in february, HAProxy persistent session cookie will not 
be working anymore for sites embedded into iframe on multiple domains.


See issue https://github.com/haproxy/haproxy/issues/361

Have you planned something to manage that point soon ?


Hi,

Here is a quick patch that should fix the issue. It is a generic way to add 
attributes to a cookie. For instance:


   cookie SRV insert secure attr "SameSite=Strict"

Any comments ?

--
Christopher Faulet
>From 8ccc4396ed93ac91f24595061f5b29e28797116a Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Tue, 21 Jan 2020 11:06:48 +0100
Subject: [PATCH] MINOR: proxy/http-ana: Add support of extra attributes for
 the cookie directive

It is now possible to insert any attribute when a cookie is inserted by
HAProxy. Any value may be set, no check is performed except the syntax validity
(CTRL chars and ';' are forbidden). For instance, it may be used to add the
SameSite attribute:

cookie SRV insert attr "SameSite=Strict"

The attr option may be repeated to add several attributes.

This patch should fix the issue #361.
---
 doc/configuration.txt |  7 ++-
 include/types/proxy.h |  1 +
 src/cfgparse-listen.c | 30 +-
 src/haproxy.c |  1 +
 src/http_ana.c|  3 +++
 5 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 93b9c6543..0988b3034 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -3340,7 +3340,7 @@ compression offload
 cookie  [ rewrite | insert | prefix ] [ indirect ] [ nocache ]
   [ postonly ] [ preserve ] [ httponly ] [ secure ]
   [ domain  ]* [ maxidle  ] [ maxlife  ]
-  [ dynamic ]
+  [ dynamic ] [ attr  ]
   Enable cookie-based persistence in a backend.
   May be used in sections :   defaults | frontend | listen | backend
  yes   |no|   yes  |   yes
@@ -3499,6 +3499,11 @@ cookie  [ rewrite | insert | prefix ] [ indirect ] [ nocache ]
   The cookie will be regenerated each time the IP address change,
   and is only generated for IPv4/IPv6.
 
+attr  This option tells haproxy to add an extra attribute when a
+  cookie is inserted. The attribute value can contain any
+  characters except control ones or ";". This option may be
+  repeated.
+
   There can be only one persistence cookie per HTTP backend, and it can be
   declared in a defaults section. The value of the cookie will be the value
   indicated after the "cookie" keyword in a "server" statement. If no cookie
diff --git a/include/types/proxy.h b/include/types/proxy.h
index c018c26f8..c6b56aa5b 100644
--- a/include/types/proxy.h
+++ b/include/types/proxy.h
@@ -338,6 +338,7 @@ struct proxy {
 	int  cookie_len;			/* strlen(cookie_name), computed only once */
 	char *cookie_domain;			/* domain used to insert the cookie */
 	char *cookie_name;			/* name of the cookie to look for */
+	char *cookie_attrs; /* list of attributes to add to the cookie */
 	char *dyncookie_key;			/* Secret key used to generate dynamic persistent cookies */
 	unsigned int cookie_maxidle;		/* max idle time for this cookie */
 	unsigned int cookie_maxlife;		/* max life time for this cookie */
diff --git a/src/cfgparse-listen.c b/src/cfgparse-listen.c
index 86d1f3366..3f16a2517 100644
--- a/src/cfgparse-listen.c
+++ b/src/cfgparse-listen.c
@@ -326,6 +326,8 @@ int cfg_parse_listen(const char *file, int linenum, char **args, int kwm)
  curproxy->rdp_cookie_name = strdup(defproxy.rdp_cookie_name);
 			curproxy->rdp_cookie_len = defproxy.rdp_cookie_len;
 
+			if (defproxy.cookie_attrs)
+curproxy->cookie_attrs = strdup(defproxy.cookie_attrs);
 
 			if (defproxy.lbprm.arg_str)
 curproxy->lbprm.arg_str = strdup(defproxy.lbprm.arg_str);
@@ -476,6 +478,7 @@ int cfg_parse_listen(const char *file, int linenum, char **args, int kwm)
 		free(defproxy.rdp_cookie_name);
 		free(defproxy.dyncookie_key);
 		free(defproxy.cookie_domain);
+		free(defproxy.cookie_attrs);
 		free(defproxy.lbprm.arg_str);
 		free(defproxy.capture_name);
 		free(defproxy.monitor_uri);
@@ -988,9 +991,34 @@ int cfg_parse_listen(const char *file, int linenum, char **args, int kwm)
 	err_code |= ERR_WARN;
 curproxy->ck_opts |= PR_CK_DYNAMIC;
 			}
+			else if (!strcmp(args[cur_arg], "attr")) {
+char *val;
+if (!*args[cur_arg + 1]) {
+	ha_alert("parsing [%s:%d]: '%s' expects  as argument.\n",
+		 file, linenum, args[cur_arg]);
+	err_code |= ERR_ALERT | ERR_FATAL;
+	goto out;
+}
+val = args[cur_arg + 1];
+while (*val) {
+	if (iscntrl(*val) || *val == ';') {
+		ha_alert("parsing [%s:%d]: character '%%x%02X' is not permitted in attribute value.\n",
+			 file, linenum, *val);
+		err_code |= ERR_ALERT | ERR_FATAL;
+		

Re: [PATCH] ssl certificates load speedup and dedup (pem/ctx)

[Emmanuel Hocdet]

Hi,Patches updated, depend on "[PATCH] BUG/MINOR: ssl: ssl_sock_load_pem_into_ckch is not consistent"++ManuLe 10 avr. 2019 à 13:23, Emmanuel Hocdet  a écrit :Hi,Updated patch serie:Fix OpenSSL < 1.0.2 compatibilty.More generic key for issuers ebtree.++Manu

0001-MINOR-ssl-add-issuer-path-directive.patch
Description: Binary data


0002-MINOR-ssl-cli-set-ssl-issuer-load-an-issuer-certific.patch
Description: Binary data

Re: SameSite attribute for persistent session cookie

[Tim Düsterhus]

Christopher,

Am 21.01.20 um 11:49 schrieb Christopher Faulet:
> Any comments ?
> 

I don't need it myself, but I want to mention that it should be
backported, because the current situation can be "considered a bug" (a
feature now longer works due to changes in the ecosystem). I guess the
patch is fairly low risk, so backport until 1.8 or so?

Best regards
Tim Düsterhus

Re: SameSite attribute for persistent session cookie

[Lukas Tribus]

Hello,

On Tue, 21 Jan 2020 at 13:09, Tim Düsterhus  wrote:
> I don't need it myself, but I want to mention that it should be
> backported, because the current situation can be "considered a bug" (a
> feature now longer works due to changes in the ecosystem). I guess the
> patch is fairly low risk, so backport until 1.8 or so?

I agree we probably have to backport this (now) necessary *feature*,
but I don't believe there is a need to masquerade it as a bug.


Lukas

RE: SameSite attribute for persistent session cookie

[mickael.bride]

Hello,

I have tested the patch provided by Christopher.
It seems to work well.
Do you know if it will be available in an official release soon?
Agree with the backport on 1.X branch, with the same question for the planning.

Thank you,

Mickaël

-Message d'origine-
De : Lukas Tribus [mailto:li...@ltri.eu] 
Envoyé : mardi 21 janvier 2020 13:53
À : Tim Düsterhus
Cc : Christopher Faulet; BRIDE Mickaël SCE/OGSB; haproxy@formilux.org
Objet : Re: SameSite attribute for persistent session cookie

Hello,

On Tue, 21 Jan 2020 at 13:09, Tim Düsterhus  wrote:
> I don't need it myself, but I want to mention that it should be
> backported, because the current situation can be "considered a bug" (a
> feature now longer works due to changes in the ecosystem). I guess the
> patch is fairly low risk, so backport until 1.8 or so?

I agree we probably have to backport this (now) necessary *feature*,
but I don't believe there is a need to masquerade it as a bug.


Lukas

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

Re: [PATCH] introduce ARM64 travis-ci builds

[Willy Tarreau]

On Sun, Jan 19, 2020 at 12:18:00PM +0500,  ??? wrote:
> hello,
> 
> sometimes arm64 builds fails, I think it is good chance to introduce
> regular builds
> and fix them.
> 
> also, few small improvements.

Merged, thanks Ilya. Next time, please be stricter and split your
additions and your small improvements as it can help track down issues
or do partial reverts.

Willy

Re: [PATCH] better anti replay check

[Willy Tarreau]

On Sun, Jan 19, 2020 at 12:22:17PM +0500,  ??? wrote:
> Hello,
> 
> let us check constants, not openssl versions.

Makes sense, thanks. Now merged (and added a commit message).

Willy

Re: SameSite attribute for persistent session cookie

[Willy Tarreau]

Hi guys,

On Tue, Jan 21, 2020 at 11:49:43AM +0100, Christopher Faulet wrote:
> Le 21/01/2020 à 09:14, mickael.br...@orange.com a écrit :
> > Hello,
> > 
> > With Chrome 80 release in february, HAProxy persistent session cookie
> > will not be working anymore for sites embedded into iframe on multiple
> > domains.
> > 
> > See issue https://github.com/haproxy/haproxy/issues/361
> > 
> > Have you planned something to manage that point soon ?

Well, first, let's cool down a little bit. Browsers normally don't
break the web, or when they do so, it takes years or decades. Otherwise
their users simply roll back to the previous version or switch to more
conservative competitors. If some sites are totally insecure and stop
working, it will not be a big loss but these sites will not change any
of their components either. Most of the internet's infrastructure cannot
afford to perform major upgrades to new compoents just because some
browser developers woke up a morning thinking how cool it could be to
drop support for something currently working fine.

> Here is a quick patch that should fix the issue. It is a generic way to add
> attributes to a cookie. For instance:
> 
>cookie SRV insert secure attr "SameSite=Strict"
> 
> Any comments ?

I do :-) We should add "*" after the "[ attr ... ]" field in the doc
since you allow to repeat the attribute. I did it and merged it.

Thanks!
Willy

Re: [PATCH] MEDIUM: dns: support for Additional section

[Willy Tarreau]

Hi Baptiste,

On Tue, Jan 21, 2020 at 10:38:37AM +0100, Baptiste wrote:
> Hi there,
> 
> For those using DNS service discovery through SRV record, you might be
> aware that HAProxy is quite verbose with your DNS server: it does one SRV
> query + 1 A/ per server found in the SRV response.
> This patch aims at improving this behavior par using first Additional
> records if available and relevant. If none found, previous behavior will
> apply (on a per server basis).
> This is behavior defined in RFC 2782 for DNS SRV records.

Interesting, thanks for this. I've merged it, I count on you to recheck
the few TODO points that appear in this patch before the final release.

Thanks,
Willy

Re: [PATCH] improving ssl defines

[Willy Tarreau]

Hi Ilya,

On Sat, Jan 18, 2020 at 06:47:48PM +0500,  ??? wrote:
> Hello,
> 
> let us switch to constants check, not versions.
> 
> cheers,
> Ilya Shipitcin

> From a8b68e746bb71c4fee65a05bea8287ad970c979c Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Sat, 18 Jan 2020 18:42:45 +0500
> Subject: [PATCH] BUG/MINOR: ssl: fix build on openssl-1.1.0
> 
> while working on issue #429, I built various openssl versions,
> let us improve ssl defines, switch to features, not versions

What is the build issue you've encountered exactly (and/or in what
specific environment), and should this build fix be backported, and if
so, how far ?

Thanks,
Willy

Re: [PATCH] improving ssl defines

[Илья Шипицин]

ср, 22 янв. 2020 г. в 11:24, Willy Tarreau :

> Hi Ilya,
>
> On Sat, Jan 18, 2020 at 06:47:48PM +0500,  ??? wrote:
> > Hello,
> >
> > let us switch to constants check, not versions.
> >
> > cheers,
> > Ilya Shipitcin
>
> > From a8b68e746bb71c4fee65a05bea8287ad970c979c Mon Sep 17 00:00:00 2001
> > From: Ilya Shipitsin 
> > Date: Sat, 18 Jan 2020 18:42:45 +0500
> > Subject: [PATCH] BUG/MINOR: ssl: fix build on openssl-1.1.0
> >
> > while working on issue #429, I built various openssl versions,
> > let us improve ssl defines, switch to features, not versions
>
> What is the build issue you've encountered exactly (and/or in what
> specific environment), and should this build fix be backported, and if
> so, how far ?
>
>
I think it should not be backported.

I've taken openssl branches (master, openssl_1_1_1 and openssl_1_1_0) and
built haproxy against various commits (not tagged as releases).
sometimes build fail, I ended with changing "ifdef" from
version-dependendent (which is not accurate) to feature dependent.

I can find particular commits, but I think it is not important since
released versions of openssl build just fine (I'll provide detailed info if
build will ever fail on openssl release).



> Thanks,
> Willy
>

Re: [PATCH] CLEANUP: Consistently `unsigned int` for bitfields

[Willy Tarreau]

On Sat, Jan 18, 2020 at 11:41:58AM +0100, Tim Düsterhus wrote:
> Fair enough. In the specific implementation of gcc it might be okay. But
> that doesn't say anything about clang (but I guess it's okay as well).

Clang tries hard to support whatever gcc does and when I mean gcc I
implicitly also mean clang (and very likely icc as well for those who
care).

> > For this reason I'd like to get the signed-vs-unsigned part merged.
> 
> Feel free to edit around in my patch to remove the bits that change from
> something to `int` and leave the adding of the `unsigned` in there. Or
> drop my patch, create your own one and add me as Co-authored-by or
> Reported-by or whatever.

OK so I simply edited your patch.

> While doing so please check on the `struct pat_time` I mentioned in my
> previous email.

Ah yes, good point. I've just checked, I added this in 2007 and never
implemented the time range parser. I we managed not to need if for the
last 13 years, I think we don't need it and the day we need it we might
do it differently, so I'm simply removing that definition.

thanks!
Willy

Re: [PATCH] MINOR: http_act: enforce capture rule id checking in frontends only

[Willy Tarreau]

Hi Baptiste,

On Thu, Jan 16, 2020 at 02:50:30PM +0100, Baptiste wrote:
> From c8192107c7055e36a6b6ab9b262b448a52346776 Mon Sep 17 00:00:00 2001
> From: Baptiste Assmann 
> Date: Thu, 16 Jan 2020 14:34:22 +0100
> Subject: [PATCH] MINOR: http_act: don't check capture id in backend
(...)

I retagged it as BUG/MINOR since it's indeed a fix, and marked it for
backport to all stable versions. Thanks!

Willy

Re: [PATCH] improving ssl defines

[Willy Tarreau]

On Wed, Jan 22, 2020 at 11:32:43AM +0500,  ??? wrote:
> I've taken openssl branches (master, openssl_1_1_1 and openssl_1_1_0) and
> built haproxy against various commits (not tagged as releases).
> sometimes build fail, I ended with changing "ifdef" from
> version-dependendent (which is not accurate) to feature dependent.
> 
> I can find particular commits, but I think it is not important since
> released versions of openssl build just fine (I'll provide detailed info if
> build will ever fail on openssl release).

OK thanks, I'll try to summarize that into the commit message.

Willy

Re: Enhancement plugin feature for haproxy

[Willy Tarreau]

On Mon, Jan 20, 2020 at 10:06:20PM +0100, Christopher Faulet wrote:
> Nuster evolves in parallel of
> HAProxy. It is a fork of it, it is not a patchset on top of it. The nuster
> developer never tried to make its project compatible with HAProxy. Or at
> least, he never asked anything on the mailing list. So, of course, it is its
> own right. There is no problem with that. But it could be a good idea to
> have a better view on how the project will evolve to evaluate the pertinence
> of a nuster plugin. Honestly, if you ever do the effort to work on it, it
> could be better to rewrite all the project as a plugin of HAProxy and not a
> fork of it. If so, it is probably a better idea to keep it in a separate
> repository though. This will be easier to push new features, without the
> burden to submit the patches on the ML.

I totally agree with this. If some minor extensions to haproxy would be
needed to do his thing better (maybe one hook here and there), we could
get them merged to ease his maintenance as long as they have zero impact
on the rest. But given that the project has been evolving for a few years
now, occasionally rebasing on new version, I guess the developer possibly
makes a living from his fork and has no particular interest in seeing his
code more easily used without him being kept in the loop. Of couse I could
be totally wrong but that's what it makes me think of. I don't think we
should bother him. He took care of renaming the project so as to present
it as a self-contained cache and not as a load balancer, and as such he
doesn't cause any harm to the haproxy project. And he seems to be doing
his job right by regularly merging stable branches, so I'm not seeing
anything wrong there that we should encourage to change. If all projects
forks were done this way, we'd all have less crap installed on our machines.

Of course it would be nice if he would participate a bit to the project,
but well, how could we expect any contribution back from anyone using
haproxy ? He will already have a tough work migrating to HTX :-)

Aleks, if you're interested in this project, I think you should contact
him. I suspect he will tell you he only covers the caching part and uses
haproxy only as the HTTP/TCP engine to run his cache, as is visible in
his example config, and that if you want to use a load balancer, he will
invite you to use a separate haproxy process. And that's important given
that he's doing file system accesses (hence high latencies and limited
security)!

Regards,
Willy