Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Willy Tarreau]

On Mon, Dec 03, 2018 at 11:12:00PM +0100, Lukas Tribus wrote:
> > This is a known bug. But because a lack of time, I did not send my
> > patches. Could you confirm they fix your bug ?
> 
> Confirmed, this works with your patches, thanks!

Great, merged now, thanks.

Willy

Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Lukas Tribus]

Hi Christopher,


On Mon, 3 Dec 2018 at 22:55, Christopher Faulet  wrote:
>
> Le 03/12/2018 à 21:48, Lukas Tribus a écrit :
> >
> > I gave HTX it a quick spin and what I noticed is that with htx enabled
> > and a plaintext http/1.1 port 80 backend, it works fine when the
> > frontend connection is http/1.1, but when the frontend connection is
> > h2, haproxy just sends plaintext h2 to the backend:
> >
> > 0004:my-https-frontend.accept(0004)=0008 from [10.0.0.34:56310] ALPN=h2
> > 0004:my-https-frontend.clireq[0008:]: GET / HTTP/2.0
> > 0004:my-https-frontend.clihdr[0008:]: user-agent: curl/7.58.0
> > 0004:my-https-frontend.clihdr[0008:]: accept: */*
> > 0004:my-https-frontend.clihdr[0008:]: host: example.org
> > 0004:my-backend.srvrep[0008:0009]: HTTP/1.1 505 HTTP Version Not 
> > Supported
> > 0004:my-backend.srvhdr[0008:0009]: Server: nginx/1.14.0 (Ubuntu)
> > 0004:my-backend.srvhdr[0008:0009]: Date: Mon, 03 Dec 2018 20:20:50 GMT
> > 0004:my-backend.srvhdr[0008:0009]: Content-Type: text/html
> > 0004:my-backend.srvhdr[0008:0009]: Content-Length: 212
> > 0004:my-backend.srvhdr[0008:0009]: Connection: close
> > 0004:my-backend.srvcls[0008:adfd]
> > 0004:my-backend.clicls[0008:adfd]
> > 0004:my-backend.closed[0008:adfd]
> >
> > Which in this case returns HTTP/1.1 505 as h2 is not enabled on the
> > backend (and being plaintext port 80 with no ALPN negotiation it is
> > also unlikely).
> >
>
> Hi Lukas,
>
> This is a known bug. But because a lack of time, I did not send my
> patches. Could you confirm they fix your bug ?

Confirmed, this works with your patches, thanks!

cheers,
lukas

Re: RSA and ECC not working as expected

[Lukas Tribus]

Hello Mildis,


On Mon, 3 Dec 2018 at 22:19, Mildis  wrote:
>
> Hi,
>
> I'm using 1.8.14 and I tried to follow 
> https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/
>  but all I'm getting in the log is

I'd recommend to ignore this blog post. Haproxy can do ECC/RSA cert
switching itself since some time now and I have some doubts about
req.ssl_ec_ext still actually correctly matching ECC support with
todays browsers and TLS stacks.

Read the docs about the crt keyword:
https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt

The gist of it is that:
"crt example.pem" loads "example.pem.ecdsa" as ECC and
"example.pem.rsa" as RSA certificate, and selects the correct one
based on client support (by actually using the correct openssl
features, not payload matching in TCP mode). This makes it easy to
implement ECC/RSA switching without a dedicated TCP based
frontend/backend.



> Why is SC the only answer ?
> Am I missing something ?

If I'd have to take a guess I would say you probably downgrade haproxy
privileges to a non-root user, which is missing the privileges to
access the unix socket that was bound by root. Use the user keyword on
the unix socket bind statement to use a specific user for the unix
socket:

https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-user


chroot may also be an issue, if you are using it.


Regards,
Lukas

Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Willy Tarreau]

On Mon, Dec 03, 2018 at 10:55:32PM +0100, Christopher Faulet wrote:
> This is a known bug. But because a lack of time, I did not send my patches.
> Could you confirm they fix your bug ?

Our mails have crossed :-) At first glance I think your patch should indeed
address Lukas' and my problem! Too late for me to merge this evening, I'll
do stupid things, I'll check pending patches tomorrow morning.

Thanks,
Willy

Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Christopher Faulet]

Le 03/12/2018 à 21:48, Lukas Tribus a écrit :


I gave HTX it a quick spin and what I noticed is that with htx enabled
and a plaintext http/1.1 port 80 backend, it works fine when the
frontend connection is http/1.1, but when the frontend connection is
h2, haproxy just sends plaintext h2 to the backend:

0004:my-https-frontend.accept(0004)=0008 from [10.0.0.34:56310] ALPN=h2
0004:my-https-frontend.clireq[0008:]: GET / HTTP/2.0
0004:my-https-frontend.clihdr[0008:]: user-agent: curl/7.58.0
0004:my-https-frontend.clihdr[0008:]: accept: */*
0004:my-https-frontend.clihdr[0008:]: host: example.org
0004:my-backend.srvrep[0008:0009]: HTTP/1.1 505 HTTP Version Not Supported
0004:my-backend.srvhdr[0008:0009]: Server: nginx/1.14.0 (Ubuntu)
0004:my-backend.srvhdr[0008:0009]: Date: Mon, 03 Dec 2018 20:20:50 GMT
0004:my-backend.srvhdr[0008:0009]: Content-Type: text/html
0004:my-backend.srvhdr[0008:0009]: Content-Length: 212
0004:my-backend.srvhdr[0008:0009]: Connection: close
0004:my-backend.srvcls[0008:adfd]
0004:my-backend.clicls[0008:adfd]
0004:my-backend.closed[0008:adfd]

Which in this case returns HTTP/1.1 505 as h2 is not enabled on the
backend (and being plaintext port 80 with no ALPN negotiation it is
also unlikely).



Hi Lukas,

This is a known bug. But because a lack of time, I did not send my 
patches. Could you confirm they fix your bug ?


Thanks !
--
Christopher Faulet
>From 66ad11b4363fd5af9be0c91e652efa080204dee6 Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Mon, 3 Dec 2018 13:58:44 +0100
Subject: [PATCH 1/2] MINOR: htx: Rename functions htx_*_to_str() to be H1
 specific

"_to_h1" suffix is now used because these function produce H1 strings. It avoids
any ambiguity on the output format.
---
 include/proto/htx.h | 10 +-
 src/http_fetch.c|  6 +++---
 src/htx.c   | 20 ++--
 src/mux_h1.c| 12 ++--
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/include/proto/htx.h b/include/proto/htx.h
index f15d9312b..e59bb4f48 100644
--- a/include/proto/htx.h
+++ b/include/proto/htx.h
@@ -56,11 +56,11 @@ struct htx_blk *htx_add_trailer(struct htx *htx, const struct ist tlr);
 struct htx_blk *htx_add_oob(struct htx *htx, const struct ist oob);
 struct htx_blk *htx_add_data_before(struct htx *htx, const struct htx_blk *ref, const struct ist data);
 
-int htx_reqline_to_str(const struct htx_sl *sl, struct buffer *chk);
-int htx_stline_to_str(const struct htx_sl *sl, struct buffer *chk);
-int htx_hdr_to_str(const struct ist n, const struct ist v, struct buffer *chk);
-int htx_data_to_str(const struct ist data, struct buffer *chk, int chunked);
-int htx_trailer_to_str(const struct ist tlr, struct buffer *chk);
+int htx_reqline_to_h1(const struct htx_sl *sl, struct buffer *chk);
+int htx_stline_to_h1(const struct htx_sl *sl, struct buffer *chk);
+int htx_hdr_to_h1(const struct ist n, const struct ist v, struct buffer *chk);
+int htx_data_to_h1(const struct ist data, struct buffer *chk, int chunked);
+int htx_trailer_to_h1(const struct ist tlr, struct buffer *chk);
 
 /* Functions and macros to get parts of the start-line or legnth of these
  * parts
diff --git a/src/http_fetch.c b/src/http_fetch.c
index 884a32049..81f6669c9 100644
--- a/src/http_fetch.c
+++ b/src/http_fetch.c
@@ -628,7 +628,7 @@ static int smp_fetch_hdrs(const struct arg *args, struct sample *smp, const char
 struct ist n = htx_get_blk_name(htx, blk);
 struct ist v = htx_get_blk_value(htx, blk);
 
-if (!htx_hdr_to_str(n, v, temp))
+if (!htx_hdr_to_h1(n, v, temp))
 	return 0;
 			}
 			else if (type == HTX_BLK_EOH) {
@@ -856,7 +856,7 @@ static int smp_fetch_body(const struct arg *args, struct sample *smp, const char
 			if (type == HTX_BLK_EOM || type == HTX_BLK_EOD)
 break;
 			if (type == HTX_BLK_DATA) {
-if (!htx_data_to_str(htx_get_blk_value(htx, blk), temp, 0))
+if (!htx_data_to_h1(htx_get_blk_value(htx, blk), temp, 0))
 	return 0;
 			}
 		}
@@ -2531,7 +2531,7 @@ static int smp_fetch_body_param(const struct arg *args, struct sample *smp, cons
 if (type == HTX_BLK_EOM || type == HTX_BLK_EOD)
 	break;
 if (type == HTX_BLK_DATA) {
-	if (!htx_data_to_str(htx_get_blk_value(htx, blk), temp, 0))
+	if (!htx_data_to_h1(htx_get_blk_value(htx, blk), temp, 0))
 		return 0;
 }
 			}
diff --git a/src/htx.c b/src/htx.c
index a57c57d15..d5285eb6d 100644
--- a/src/htx.c
+++ b/src/htx.c
@@ -801,11 +801,11 @@ struct htx_blk *htx_add_data_before(struct htx *htx, const struct htx_blk *ref,
 	return blk;
 }
 
-/* Appends the string representation of the request line block  to the
+/* Appends the H1 representation of the request line block  to the
  * chunk . It returns 1 if data are successfully appended, otherwise it
  * returns 0.
  */
-int htx_reqline_to_str(const struct htx_sl *sl, struct buffer *chk)
+int htx_reqline_to_h1(const struct htx_sl 

Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Willy Tarreau]

Hi Lukas,

On Mon, Dec 03, 2018 at 09:48:17PM +0100, Lukas Tribus wrote:
> Would you like to see people testing their config with dev9 right now,
> without htx? Or even with htx? Of course, if you still have a number
> of items on your htx todo list, it doesn't make sense to report issues
> that you most likely are already aware of or are known, current
> limitations.

It's always interesting but let's be prudent. I have not put it on
haproxy.org yet because we know there's some breakage that could only
be discovered after integrating. I have to recheck with Christopher
the mess I did in the H2 mux because apparently my data accounting is
wrong in HTX.

> What is your preference regarding
> user-testing/issue-reporting -dev9 with or without htx at this point?

I'd suggest to be prudent (i.e. no prod) but that all reports are
interesting. Better git pull before testing as we're starting fixing
stuff and it's likely that horrible bugs will be fixed during the first
few days of the week.

> > HTX opens new possibilities by remains in experimental status at release 
> > date.
> 
> The fact that HTX remains experimental in 1.9 release is an important
> information that I feel like we will have to re-iterate a few times
> (in release-notes). It is in the docs of course, but ... people tend
> to overlook informations in the docs.

Yes you're right. In my opinion it's experimental just like H2 was
experimental in 1.8. It just means it's too young for us to claim that
it works well enough. But probably that in 3 months we'll have squashed
enough bugs to consider it safe enough for use.

> >  - server-side connection pooling : idle connections don't quit anymore
> >if the front connection vanishes, they can remain on the server to be
> >used by another one. Expect a few minor adjustments on this part soon.
> 
> For the record, this does not depend on htx being enabled, this works
> with legacy mode?

It also works with legacy mode. But the client needs not to advertise
the close for this (otherwise the server side connection will still be
closed before we have an opportunity to keep it alive). I'm thinking
about whether or not we should have an option to force keep-alive even
when there's a close on the front connection. It can prove to be useful,
and will probably be a one-liner (in addition to the config parsing). I'd
rather want to spend our energy on stabilizing everything first ;-)

> I gave HTX it a quick spin and what I noticed is that with htx enabled
> and a plaintext http/1.1 port 80 backend, it works fine when the
> frontend connection is http/1.1, but when the frontend connection is
> h2, haproxy just sends plaintext h2 to the backend:
> 
> 0004:my-https-frontend.accept(0004)=0008 from [10.0.0.34:56310] ALPN=h2
> 0004:my-https-frontend.clireq[0008:]: GET / HTTP/2.0
> 0004:my-https-frontend.clihdr[0008:]: user-agent: curl/7.58.0
> 0004:my-https-frontend.clihdr[0008:]: accept: */*
> 0004:my-https-frontend.clihdr[0008:]: host: example.org
> 0004:my-backend.srvrep[0008:0009]: HTTP/1.1 505 HTTP Version Not Supported
> 0004:my-backend.srvhdr[0008:0009]: Server: nginx/1.14.0 (Ubuntu)
> 0004:my-backend.srvhdr[0008:0009]: Date: Mon, 03 Dec 2018 20:20:50 GMT
> 0004:my-backend.srvhdr[0008:0009]: Content-Type: text/html
> 0004:my-backend.srvhdr[0008:0009]: Content-Length: 212
> 0004:my-backend.srvhdr[0008:0009]: Connection: close

In fact it's not plaintext H2, it's H1 but with H2 advertised as the
version. H2 doesn't have a version but we needed to encode one in HTX
to transport HTTP/0.9-1.0-1.1. Today we've discussed this point with
Christopher and came to the conclusion that it should be the H1 mux
that should write 1.1 in output when the HTX version is >= 1.1, since
the on-wire format is 1.1.


> Which in this case returns HTTP/1.1 505 as h2 is not enabled on the
> backend (and being plaintext port 80 with no ALPN negotiation it is
> also unlikely).

I first noticed it in the exact opposite direction, the response was
2.0 and passed to curl asking it in 1.1, which was confused and
possibly considered it as 1.0, waiting for the close.

Thanks, this typically is the type of useful reports that help us
put the finger on well defined issues in fact!

Cheers,
Willy

RSA and ECC not working as expected

[Mildis]

Hi,

I'm using 1.8.14 and I tried to follow 
https://www.haproxy.com/blog/serving-ecc-and-rsa-certificates-on-same-ip-with-haproxy/
 

 but all I'm getting in the log is 

ssl-relay ssl-rsa/rsa 1/-1/0 0 SC 1/1/0/0/3 0/0

Currently I do not have an ECC cert so I'm doing tests with an RSA only backend

The relevant configuration is 

frontend ssl-relay
mode tcp
bind ${HAPROXY_VRRP}:443
bind ${HAPROXY_IPV4}:443
bind ${HAPROXY_IPV6}:443
default_backend ssl-rsa

backend ssl-rsa
mode tcp
server rsa unix@/var/run/haproxy/haproxy_ssl_rsa.sock send-proxy-v2

listen all-ssl
mode http
bind unix@/var/run/haproxy/haproxy_ssl_rsa.sock accept-proxy ssl crt 
company.crt 

#capture request  header Host len 50
#capture response header Location len 50
#capture request header User-Agent len 50

http-request set-header X-Forwarded-Proto https
http-request set-header X-Forwarded-Port 443
http-request set-header X-Forwarded-Host %[ssl_fc_sni]


http-response set-header Strict-Transport-Security max-age=31536000;\ 
includeSubDomains

acl secured_cookie res.hdr(Set-Cookie),lower -m sub secure
rspirep ^(Set-Cookie:.*) \1;\ Secure unless secured_cookie


The all-ssl section is where all the routing logic take place based on 
hdr(host) and path_beg combinations to use a specific backend.

Why is SC the only answer ?
Am I missing something ?

Thanks,
Mildis

Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Lukas Tribus]

Hello Willy,


On Sun, 2 Dec 2018 at 20:30, Willy Tarreau  wrote:
>
> Hi,
>
> HAProxy 1.9-dev9 was released on 2018/12/02. It added 147 new commits
> after version 1.9-dev8.
>
> This version will give some of us a bit of relief. It is the first one in
> one year which finally integrates all the ongoing parallel development! I
> thought about calling it -rc1 but I remembered that mixing -rc and -dev
> causes some confusion, so it's dev9.
>
> So we're starting to see the light at the end of the tunnel, which marks
> the hopefully soon completion of something that started really bad a
> year ago when we started to modify multiple interdependent areas at the
> same time, leaving each developer with limited ways to test their code
> in target situation. Just to illustrate, HTX development needed idle
> connections rework to get keep-alive, which required the connection
> management to be replaced, which in turn couldn't be tested without a
> multi-stream outgoing mux (H2), which itself couldn't be implemented
> before HTX... Now the loop is closed!

Great work everyone!

Would you like to see people testing their config with dev9 right now,
without htx? Or even with htx? Of course, if you still have a number
of items on your htx todo list, it doesn't make sense to report issues
that you most likely are already aware of or are known, current
limitations. What is your preference regarding
user-testing/issue-reporting -dev9 with or without htx at this point?


> HTX opens new possibilities by remains in experimental status at release date.

The fact that HTX remains experimental in 1.9 release is an important
information that I feel like we will have to re-iterate a few times
(in release-notes). It is in the docs of course, but ... people tend
to overlook informations in the docs.



>  - server-side connection pooling : idle connections don't quit anymore
>if the front connection vanishes, they can remain on the server to be
>used by another one. Expect a few minor adjustments on this part soon.

For the record, this does not depend on htx being enabled, this works
with legacy mode?


I gave HTX it a quick spin and what I noticed is that with htx enabled
and a plaintext http/1.1 port 80 backend, it works fine when the
frontend connection is http/1.1, but when the frontend connection is
h2, haproxy just sends plaintext h2 to the backend:

0004:my-https-frontend.accept(0004)=0008 from [10.0.0.34:56310] ALPN=h2
0004:my-https-frontend.clireq[0008:]: GET / HTTP/2.0
0004:my-https-frontend.clihdr[0008:]: user-agent: curl/7.58.0
0004:my-https-frontend.clihdr[0008:]: accept: */*
0004:my-https-frontend.clihdr[0008:]: host: example.org
0004:my-backend.srvrep[0008:0009]: HTTP/1.1 505 HTTP Version Not Supported
0004:my-backend.srvhdr[0008:0009]: Server: nginx/1.14.0 (Ubuntu)
0004:my-backend.srvhdr[0008:0009]: Date: Mon, 03 Dec 2018 20:20:50 GMT
0004:my-backend.srvhdr[0008:0009]: Content-Type: text/html
0004:my-backend.srvhdr[0008:0009]: Content-Length: 212
0004:my-backend.srvhdr[0008:0009]: Connection: close
0004:my-backend.srvcls[0008:adfd]
0004:my-backend.clicls[0008:adfd]
0004:my-backend.closed[0008:adfd]

Which in this case returns HTTP/1.1 505 as h2 is not enabled on the
backend (and being plaintext port 80 with no ALPN negotiation it is
also unlikely).



Regards,
Lukas

Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Willy Tarreau]

Hi Aleks,

On Mon, Dec 03, 2018 at 04:03:57PM +0100, Aleksandar Lazic wrote:
> Available multiplexer protocols :
> (protocols marked as  cannot be specified using 'proto' keyword)
>   h2 : mode=HTXside=FE|BE
>   h2 : mode=HTTP   side=FE
> : mode=HTXside=FE|BE
> : mode=TCP|HTTP   side=FE|BE
> 
> I'm a little bit confused as there is no h1 in the protocol output above. I
> think the "default" is h1.

It is expected. In fact if a connection comes over TLS without advertising
any ALPN, it's supposed to be H1. That's the reason why the protocol is not
enforced and is indeed the default one. We should probably add the mux's
name in addition to what is displayed though, because the two defaults are
different, the first one us "mux-h1" and the second one is "mux-pt".

> >   - server-side connection multiplexing (needed for H2, H3 later, maybe
> > one day FCGI, who knows)
> 
> I hope that the FCGI solutions move to uwsgi as this tool have a great amount 
> of
> languages implemented to run as apps and it speaks http(s).

I remember having talked about it a few years ago and being told it was
disappearing. I don't know whom to believe regarding all of these. Anyway
fcgi, uwsgi or anything else roughly follow the same principle and that's
what matters.

Cheers,
Willy

Re: [ANNOUNCE] haproxy-1.9-dev9 : the last mile

[Aleksandar Lazic]

Am 02.12.2018 um 20:29 schrieb Willy Tarreau:
> Hi,
> 
> HAProxy 1.9-dev9 was released on 2018/12/02. It added 147 new commits
> after version 1.9-dev8.

Image is now updated ;-)

https://hub.docker.com/r/me2digital/haproxy19/

###
HA-Proxy version 1.9-dev9 2018/12/02
Copyright 2000-2018 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
-Wno-missing-field-initializers -Wtype-limits
  OPTIONS = USE_LINUX_SPLICE=1 USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1
USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_TFO=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.1.1a  20 Nov 2018
Running on OpenSSL version : OpenSSL 1.1.1a  20 Nov 2018
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.5
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT
IP_FREEBIND
Built with zlib version : 1.2.7
Running on zlib version : 1.2.7
Compression algorithms supported : identity("identity"), deflate("deflate"),
raw-deflate("deflate"), gzip("gzip")
Built with PCRE version : 8.32 2012-11-30
Running on PCRE version : 8.32 2012-11-30
PCRE library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with multi-threading support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
  h2 : mode=HTXside=FE|BE
  h2 : mode=HTTP   side=FE
: mode=HTXside=FE|BE
: mode=TCP|HTTP   side=FE|BE

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
###

I'm a little bit confused as there is no h1 in the protocol output above. I
think the "default" is h1.

> This version will give some of us a bit of relief. It is the first one in
> one year which finally integrates all the ongoing parallel development! I
> thought about calling it -rc1 but I remembered that mixing -rc and -dev
> causes some confusion, so it's dev9.
> 
> So we're starting to see the light at the end of the tunnel, which marks
> the hopefully soon completion of something that started really bad a
> year ago when we started to modify multiple interdependent areas at the
> same time, leaving each developer with limited ways to test their code
> in target situation. Just to illustrate, HTX development needed idle
> connections rework to get keep-alive, which required the connection
> management to be replaced, which in turn couldn't be tested without a
> multi-stream outgoing mux (H2), which itself couldn't be implemented
> before HTX... Now the loop is closed!
> 
> It doesn't mean it works well. Oh no, rest assured it's still full of
> awful bugs! But for the first time we'll be able to focus on integration
> bugs instead of focusing on bugs caused by temporary code, to experience
> integration failures later as we've been doing for one year.
> 
> So from now on, we'll focus on testing, bug fixing, code cleanups,
> polishing, and documentation. No new big stuff is expected anymore. In the
> worst case we'll revert certain things if they look too broken and appear
> unfixable (let's hope it will not be the case).
> 
> I'm quite hopeful in the next steps, having seen how all the infrastructure
> changes managed over time to much better isolate bugs, resulting in their
> diagnostic and fixing to be significantly faster than in the past.
> 
> Among the new stuff that we finally managed to integrate with this series,
> I can name :
>   - near completion of HTX porting : everything is supported, even
> redirects/http-rules/errorfiles, except Lua and cache (which may or
> may not be addressed soon, I've heard that the showstopper was the
> filters API but it's been addressed now). HTX opens new possibilities
> by remains in experimental status at release date. Ideally for 2.0
> we should have same coverage for legacy and HTX modes so that we can
> remove the legacy mode for 2.1.
> 
>   - server-side connection multiplexing (needed for H2, H3 later, maybe
> one day FCGI, who knows)

I hope that the FCGI solutions move to uwsgi as this tool have a great amount of
languages implemented to run as apps and it speaks http(s).

>   - server-side connection pooling : idle connections don't quit anymore
> if the front connection vanishes, they can remain on the server to be
> used by another one. Expect a few minor adjustments on this part soon.

Yesss ;-)

>   -

New marketing approach For Haproxy.com!!

[katie]

Owner Of Haproxy,



Hope you are doing well.

As we all know, a website is the first impression that a customer perceives  
about an organization.


You might want to understand why exactly your website is unable to acquire  
the expected traffic and business; this would be an excellent chance to  
showcase what we can offer to boost your online presence.


Well we offer tailor made services to counteract all your web problems! We  
have been successful in increasing the website visibility of our clients in  
major search engine.


Below are the factors we keep in mind while promoting your website:

- Keeping your website error free allows search engine crawlers to index  
your website right away.

- A well searched and analyzed keyword palette for maximum optimization.
- Regular updates on various social media networks for brand promotion.
- Excellent content places direct impression on the users for better  
information.


Apart from the above mentioned activities, we offer many other additional  
improvements for your website. There's been a lot to discuss and work out  
for better results on your site!


I would love to present a detailed analysis report along with errors that  
your website has and ways to improve your Google rankings. If you want I  
can fix up an appointment with one of my certified analyst for a free  
consultation on your website improvement.


Please feel free to reply me back for more information on our services and  
pricing.



Best Regards,

Katie Ruthens

Marketing Consultant