Re: [PATCH] MINOR: introduce proxy-v2-options for send-proxy-v2

[Willy Tarreau]

Hi Manu,

On Thu, Feb 01, 2018 at 05:54:46PM +0100, Emmanuel Hocdet wrote:
> Hi,
> 
> It's patch introduce proxy-v2-options for send-proxy-v2.
> Goal is to add more options from  doc/proxy-protocol.txt, especially 
> all TLS informations related to security.

OK thanks, applied. We'll see during the development cycle how this
evolves, and if this needs to change a little bit. But at least now we
have something to start with, making it more convenient to experiment
with future options.

Willy

Re: [PATCH] DOC: don't suggest using http-server-close

[Willy Tarreau]

On Thu, Feb 01, 2018 at 11:58:59PM +0100, Lukas Tribus wrote:
> Remove the old suggestion to use http-server-close mode, from the
> beginnings of keep-alive mode in commit 16bfb021 "MINOR: config: add
> option http-keep-alive").
> 
> We made http-keep-alive default in commit 70dffdaa "MAJOR: http:
> switch to keep-alive mode by default".

Now applied, thank you Lukas!
Willy

Re: redispatch still cause error response

[flamesea12]

Hello,

Thanks for the lucid explain, understood it now.


Anyway I find that haproxy slow down the requests to alive server when there is 
a server down.

Still take the test I made before,

ruby -run -ehttpd . -p8001 and ruby -run -ehttpd . -p8000 and i start haproxy 
then do a ab ab -n 2 -c 10 http://127.0.0.1:8080/

So both ruby servers start to log requests, very fast(say 100 request per 
second), meaning that haproxy forwards request very fast.

Then I killed ruby 8001, the strange thing is that ruby 8000's log becomes very 
slow(say 10 requests per seconds) for a while.

I understand that there will be some check against 8001, but why it will slow 
down the request to 8000?

Why is that?


Thanks


- Original Message -
>From: Lukas Tribus 
>To: flamese...@yahoo.co.jp 
>Cc: "haproxy@formilux.org" ; "cyril.bo...@free.fr" 
>; "lu...@ltri.eu" 
>Date: 2018/2/1, Thu 17:45
>Subject: Re: redispatch still cause error response
> 
>Hello,
>
>
>On 1 February 2018 at 04:43,   wrote:
>> Thanks for reply, any plan to support this requirement?
>>
>> If a backend server get killed when processing request, that haproxy
>> re-forwarad the request to another backend server?
>
>No, this is problematic for a number of reasons. First of all this can
>only be done for idempotent methods, and yet it could still trigger
>applications bugs. Then we would need to keep a copy of the request in
>memory, until we know for sure the response is "valid". Then we would
>need to validate the response, where every users wants something
>different. Some may ask to resend the request to another server on a
>404 response ...
>
>So no, I don't see how this can easily be achieved.
>
>
>cheers,
>Lukas
>
>
>
>

Re: haproxy http2 benchmark

[Shawn Heisey]

On 1/30/2018 7:41 PM, 龙红波 wrote:
>           h2load -n100 -c20 -m5 https://$0.172.144.113:1999/128
>           starting benchmark...
>           spawning thread #0: 20 total client(s). 100 total requests
>           TLS Protocol: TLSv1.2
>           Cipher: ECDHE-RSA-AES256-GCM-SHA384
>           Application protocol: h2
>           ..
> 
>           finished in 86.23s, 11596.77 req/s, 2.90MB/s

Are both the client and the server on the same LAN?  The usage of the
private IP address suggests that it is a LAN.  Also, the fact that you
are seeing more than 1 requests per second suggests that it is a
LAN.  I don't think you'd see that rate from one source over the Internet.

I doubt HTTP/2 is going to really make much of a difference in a
low-latency network environment like a LAN, especially if it's gigabit
or faster.  Your numbers show it to be 15 percent slower, which is
really surprising.

Try the same thing from a remote location over the Internet, where
you've got real latency.  That is the kind of situation where HTTP/2
promises to really speed things up.

I found and built h2load from source (the master branch), then did a
test similar to yours over the Internet from a client on a DSL
connection to a system running haproxy 1.8.3 with http2 configured on
the frontend.  The backend is http/1.1.  Here are the h2load options I
used and the results of three consecutive tests.  The URL was https.

I did tests with three combinations of h2load parameters.  One with
http/1.1 and no pipelining, one with http/1.1 and pipelining
(keepalive), and one with http/2.

==

--requests=500 --clients=5 --max-concurrent-streams=1
--npn-list=http/1.1 --no-tls-proto=http/1.1

finished in 19.47s, 25.67 req/s, 21.79KB/s
finished in 32.50s, 15.39 req/s, 13.06KB/s
finished in 47.48s, 10.53 req/s, 8.94KB/s

==

--requests=500 --clients=5 --max-concurrent-streams=5
--npn-list=http/1.1 --no-tls-proto=http/1.1

finished in 9.92s, 50.41 req/s, 42.78KB/s
finished in 10.76s, 46.48 req/s, 39.45KB/s
finished in 9.90s, 50.49 req/s, 42.84KB/s

==

--requests=500 --clients=5 --max-concurrent-streams=5

finished in 7.75s, 64.48 req/s, 50.33KB/s
finished in 8.07s, 61.99 req/s, 48.39KB/s
finished in 4.71s, 106.15 req/s, 82.85KB/s

==

(I did try the short option names for h2load like you had, but it just
showed the help text, and didn't do the benchmark.  So then I tried
changing them to the long form and it started working.)

Thanks,
Shawn

[PATCH] DOC: don't suggest using http-server-close

[Lukas Tribus]

Remove the old suggestion to use http-server-close mode, from the
beginnings of keep-alive mode in commit 16bfb021 "MINOR: config: add
option http-keep-alive").

We made http-keep-alive default in commit 70dffdaa "MAJOR: http:
switch to keep-alive mode by default".
---
 doc/configuration.txt | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 3665fe0..55956db 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -5769,9 +5769,6 @@ no option http-keep-alive
   available to try optimize server selection so that if the server currently
   attached to an idle connection is usable, it will be used.
 
-  In general it is preferred to use "option http-server-close" with application
-  servers, and some static servers might benefit from "option http-keep-alive".
-
   At the moment, logs will not indicate whether requests came from the same
   session or not. The accept date reported in the logs corresponds to the end
   of the previous request, and the request time corresponds to the time spent
-- 
2.7.4

Re: [PATCH] MINOR: introduce proxy-v2-options for send-proxy-v2

[Aleksandar Lazic]

Hi.

-- Originalnachricht --
Von: "Emmanuel Hocdet" 
An: "haproxy" 
Gesendet: 01.02.2018 17:54:46
Betreff: [PATCH] MINOR: introduce proxy-v2-options for send-proxy-v2


Hi,

It’s patch introduce proxy-v2-options for send-proxy-v2.
Goal is to add more options from  doc/proxy-protocol.txt, especially
all TLS informations related to security.
Can then this function replace the current one `send-proxy-v2-ssl-cn` && 
`send-proxy-v2-ssl`
Let's say when the option is 'ssl-cn' then add all three flags as in the 
current `srv_parse_send_proxy_cn` function?


http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/ssl_sock.c;hb=497959290789002b814b9021a737a3c5f14e7407#l7788
http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/ssl_sock.c;hb=497959290789002b814b9021a737a3c5f14e7407#l7796

We offer with this suggested solution a backward compatibility and the 
new function is in use.


Maybe in the next step there could be a 'tlv' option which can decode 
custom tlv's ?

http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/connection.c;hb=497959290789002b814b9021a737a3c5f14e7407#l606

Just some brainstorming ;-)

What do you mean?


++
Manu

Regards
Aleks

APhA Attendees Email List 2018

[Jennifer Ganon]

Hi,

 

Would you be interested in acquiring American Pharmacists Association
Attendees Email List 2018 for pre-show marketing campaign, Networking and
various Marketing initiatives.

 

List includes E-mail address and Contact number on an excel spread sheet.

 

Visitors Interest :

 

Ø  Pharmacy professionals

Ø  Practicing pharmacists

Ø  Pharmaceutical scientists

Ø  Student pharmacists

Ø  Pharmacy technicians

 

If you are interested please let me know so that I can get back to you with
the number of counts we have and pricing for the same.

 

Regards,

Jennifer Ganon

Business Development Executive

 

If you do not wish to receive future emails from us, please reply as 'Leave
out'

Re: Compression issues with http-server-close/httpclose

[Willy Tarreau]

On Thu, Feb 01, 2018 at 07:44:57PM +, Martin Goldstone wrote:
> Yes, the exact same configuration file, no caching or threads. We've not
> tried HTTP/2 just yet, I'll have a look at this when I'm in the office
> tomorrow.

No rush, I'll still be burried in a meeting for the last day in the week so
I still won't have time to look into it anyway. If in the mean time you can
take a look at the relevant log lines to see if you notice any particular
termination codes, or that they affect only certain requests or anything,
that would also be helpful.

Thanks!
Willy

Re: Compression issues with http-server-close/httpclose

[Martin Goldstone]

Yes, the exact same configuration file, no caching or threads. We've not
tried HTTP/2 just yet, I'll have a look at this when I'm in the office
tomorrow.

Thanks

On 1 Feb 2018 19:31, "Willy Tarreau"  wrote:

Hi guys,

On Thu, Feb 01, 2018 at 06:16:32PM +0100, Lukas Tribus wrote:
> Hello Martin,
>
> On 1 February 2018 at 17:18, Martin Goldstone 
wrote:
> > Hi,
> >
> > We've been using haproxy in docker for quite some time to provide
reverse
> > proxy facilities for many and varied application servers.  Typically,
we've
> > always used option http-server-close in the config, except for rare
> > occasions where we might need http-keep-alive (eg ntlm authentication).
We
> > also have the following in our front end configs:
> >
> > compression algo gzip
> > compression type text/html application/x-javascript text/css
> > application/javascript text/javascript text/plain text/xml
application/json
> > application/vnd.ms-fontobject application/x-font-opentype
> > application/x-font-truetype application/x-font-ttf application/xml
font/eot
> > font/opentype font/otf image/svg+xml image/vnd.microsoft.icon
> >
> > These have been working fine up to and including the most recent
release of
> > 1.7. We've recently began re-engineering our reverse proxy set up, and
as
> > part of this we want to move to 1.8. However, we've discovered that some
> > resources requested by web pages (mainly javascript and css) don't load
> > properly when using haproxy 1.8 with these options. Basically, the page
> > doesn't display and the developer toolbar in Chrome gives an error of
> > net::ERR_INCOMPLETE_CHUNKED_ENCODING or net::ERR_INVALID_CHUNKED_
ENCODING
> > against the resources that failed to load in the network pane. I haven't
> > been able to determine yet why this doesn't apply to every resource the
page
> > attempts to load, but in this case out of 20 javascript and css files, 5
> > fail to load.
> >
> > [...]
> > Can anyone offer any advice?
>
> Ok, so this is clearly a bug that has to be fixed.

I really don't see anything changing in the compression area between 1.7
and 1.8, so I'm afraid we might have been breaking something somewhere
else :-(  Just to be sure Martin, are you using the same configuration ?
No threads nor caching for example (just trying to narrow down the problem)
?

> > We've noticed that the problem goes away when using option
http-keep-alive
> > and option http-pretend-keepalive, but as the documentation suggests
that
> > http-server-close is the preferred option, we'd prefer to stick with
that.

That's a very very useful element. So there might be some breakage in the
way we manage the analysers or filters at the end of the request. I think
we had some changes in this area during 1.8.

> Yeah, that comment in the documentation stems from the introduction of
> keepalive support 8 years ago (commit 16bfb021 "MINOR: config: add
> option http-keep-alive"), I think it should be removed now. We made
> http-keep-alive the default mode 4 years ago (commit 70dffdaa "MAJOR:
> http: switch to keep-alive mode by default") and everyone is using it
> nowadays, which is why you are seeing this unfixed bug in those old
> close modes as opposed to http-keep-alive.

I agree this definitely makes sense. I'm wondering whether it surfaces
when using HTTP/2 (haproxy.org runs with both H2 and compression and
we didn't get any such report yet though).

> Really http-keep-alive is what you should use in haproxy 1.8 (and
> 1.7), as it gets all the testing (filters, compression, HTTP/2) and
> everyone is using that (default) mode. Keep-alive is safe as it does
> not reuse session between different sessions by default:
> http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-http-
reuse
>
>
> If there is agreement (Willy?) I can send a doc patch removing that
paragraph.

Oh yes please, thanks for the offer Lukas!

Willy

Re: Compression issues with http-server-close/httpclose

[Willy Tarreau]

Hi guys,

On Thu, Feb 01, 2018 at 06:16:32PM +0100, Lukas Tribus wrote:
> Hello Martin,
> 
> On 1 February 2018 at 17:18, Martin Goldstone  
> wrote:
> > Hi,
> >
> > We've been using haproxy in docker for quite some time to provide reverse
> > proxy facilities for many and varied application servers.  Typically, we've
> > always used option http-server-close in the config, except for rare
> > occasions where we might need http-keep-alive (eg ntlm authentication). We
> > also have the following in our front end configs:
> >
> > compression algo gzip
> > compression type text/html application/x-javascript text/css
> > application/javascript text/javascript text/plain text/xml application/json
> > application/vnd.ms-fontobject application/x-font-opentype
> > application/x-font-truetype application/x-font-ttf application/xml font/eot
> > font/opentype font/otf image/svg+xml image/vnd.microsoft.icon
> >
> > These have been working fine up to and including the most recent release of
> > 1.7. We've recently began re-engineering our reverse proxy set up, and as
> > part of this we want to move to 1.8. However, we've discovered that some
> > resources requested by web pages (mainly javascript and css) don't load
> > properly when using haproxy 1.8 with these options. Basically, the page
> > doesn't display and the developer toolbar in Chrome gives an error of
> > net::ERR_INCOMPLETE_CHUNKED_ENCODING or net::ERR_INVALID_CHUNKED_ENCODING
> > against the resources that failed to load in the network pane. I haven't
> > been able to determine yet why this doesn't apply to every resource the page
> > attempts to load, but in this case out of 20 javascript and css files, 5
> > fail to load.
> >
> > [...]
> > Can anyone offer any advice?
> 
> Ok, so this is clearly a bug that has to be fixed.

I really don't see anything changing in the compression area between 1.7
and 1.8, so I'm afraid we might have been breaking something somewhere
else :-(  Just to be sure Martin, are you using the same configuration ?
No threads nor caching for example (just trying to narrow down the problem) ?

> > We've noticed that the problem goes away when using option http-keep-alive
> > and option http-pretend-keepalive, but as the documentation suggests that
> > http-server-close is the preferred option, we'd prefer to stick with that.

That's a very very useful element. So there might be some breakage in the
way we manage the analysers or filters at the end of the request. I think
we had some changes in this area during 1.8.

> Yeah, that comment in the documentation stems from the introduction of
> keepalive support 8 years ago (commit 16bfb021 "MINOR: config: add
> option http-keep-alive"), I think it should be removed now. We made
> http-keep-alive the default mode 4 years ago (commit 70dffdaa "MAJOR:
> http: switch to keep-alive mode by default") and everyone is using it
> nowadays, which is why you are seeing this unfixed bug in those old
> close modes as opposed to http-keep-alive.

I agree this definitely makes sense. I'm wondering whether it surfaces
when using HTTP/2 (haproxy.org runs with both H2 and compression and
we didn't get any such report yet though).

> Really http-keep-alive is what you should use in haproxy 1.8 (and
> 1.7), as it gets all the testing (filters, compression, HTTP/2) and
> everyone is using that (default) mode. Keep-alive is safe as it does
> not reuse session between different sessions by default:
> http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-http-reuse
> 
> 
> If there is agreement (Willy?) I can send a doc patch removing that paragraph.

Oh yes please, thanks for the offer Lukas!

Willy

Re: Compression issues with http-server-close/httpclose

[Lukas Tribus]

Hello Martin,


On 1 February 2018 at 17:18, Martin Goldstone  wrote:
> Hi,
>
> We've been using haproxy in docker for quite some time to provide reverse
> proxy facilities for many and varied application servers.  Typically, we've
> always used option http-server-close in the config, except for rare
> occasions where we might need http-keep-alive (eg ntlm authentication). We
> also have the following in our front end configs:
>
> compression algo gzip
> compression type text/html application/x-javascript text/css
> application/javascript text/javascript text/plain text/xml application/json
> application/vnd.ms-fontobject application/x-font-opentype
> application/x-font-truetype application/x-font-ttf application/xml font/eot
> font/opentype font/otf image/svg+xml image/vnd.microsoft.icon
>
> These have been working fine up to and including the most recent release of
> 1.7. We've recently began re-engineering our reverse proxy set up, and as
> part of this we want to move to 1.8. However, we've discovered that some
> resources requested by web pages (mainly javascript and css) don't load
> properly when using haproxy 1.8 with these options. Basically, the page
> doesn't display and the developer toolbar in Chrome gives an error of
> net::ERR_INCOMPLETE_CHUNKED_ENCODING or net::ERR_INVALID_CHUNKED_ENCODING
> against the resources that failed to load in the network pane. I haven't
> been able to determine yet why this doesn't apply to every resource the page
> attempts to load, but in this case out of 20 javascript and css files, 5
> fail to load.
>
> [...]
> Can anyone offer any advice?

Ok, so this is clearly a bug that has to be fixed.



> We've noticed that the problem goes away when using option http-keep-alive
> and option http-pretend-keepalive, but as the documentation suggests that
> http-server-close is the preferred option, we'd prefer to stick with that.

Yeah, that comment in the documentation stems from the introduction of
keepalive support 8 years ago (commit 16bfb021 "MINOR: config: add
option http-keep-alive"), I think it should be removed now. We made
http-keep-alive the default mode 4 years ago (commit 70dffdaa "MAJOR:
http: switch to keep-alive mode by default") and everyone is using it
nowadays, which is why you are seeing this unfixed bug in those old
close modes as opposed to http-keep-alive.

Really http-keep-alive is what you should use in haproxy 1.8 (and
1.7), as it gets all the testing (filters, compression, HTTP/2) and
everyone is using that (default) mode. Keep-alive is safe as it does
not reuse session between different sessions by default:
http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4.2-http-reuse


If there is agreement (Willy?) I can send a doc patch removing that paragraph.


Regards,
Lukas

[PATCH] MINOR: introduce proxy-v2-options for send-proxy-v2

[Emmanuel Hocdet]

Hi,It’s patch introduce proxy-v2-options for send-proxy-v2.Goal is to add more options from  doc/proxy-protocol.txt, especially all TLS informations related to security.++Manu

0001-MINOR-introduce-proxy-v2-options-for-send-proxy-v2.patch
Description: Binary data

Compression issues with http-server-close/httpclose

[Martin Goldstone]

Hi,

We've been using haproxy in docker for quite some time to provide reverse
proxy facilities for many and varied application servers.  Typically, we've
always used option http-server-close in the config, except for rare
occasions where we might need http-keep-alive (eg ntlm authentication). We
also have the following in our front end configs:

compression algo gzip
compression type text/html application/x-javascript text/css
application/javascript text/javascript text/plain text/xml application/json
application/vnd.ms-fontobject application/x-font-opentype
application/x-font-truetype application/x-font-ttf application/xml font/eot
font/opentype font/otf image/svg+xml image/vnd.microsoft.icon

These have been working fine up to and including the most recent release of
1.7. We've recently began re-engineering our reverse proxy set up, and as
part of this we want to move to 1.8. However, we've discovered that some
resources requested by web pages (mainly javascript and css) don't load
properly when using haproxy 1.8 with these options. Basically, the page
doesn't display and the developer toolbar in Chrome gives an error of
net::ERR_INCOMPLETE_CHUNKED_ENCODING or net::ERR_INVALID_CHUNKED_ENCODING
against the resources that failed to load in the network pane. I haven't
been able to determine yet why this doesn't apply to every resource the
page attempts to load, but in this case out of 20 javascript and css files,
5 fail to load.

We've noticed that the problem goes away when using option http-keep-alive
and option http-pretend-keepalive, but as the documentation suggests that
http-server-close is the preferred option, we'd prefer to stick with that.

Can anyone offer any advice?

Thanks

-- 
Martin Goldstone
IT Systems Administrator
IT Services, Innovation Centre 1 (IC1)
Keele University, Keele, Staffordshire, United Kingdom, ST5 5NB
Telephone: +44 1782 734457
G+: http://google.com/+MartinGoldstoneKeele

Re: redispatch still cause error response

[Lukas Tribus]

Hello,


On 1 February 2018 at 04:43,   wrote:
> Thanks for reply, any plan to support this requirement?
>
> If a backend server get killed when processing request, that haproxy
> re-forwarad the request to another backend server?

No, this is problematic for a number of reasons. First of all this can
only be done for idempotent methods, and yet it could still trigger
applications bugs. Then we would need to keep a copy of the request in
memory, until we know for sure the response is "valid". Then we would
need to validate the response, where every users wants something
different. Some may ask to resend the request to another server on a
404 response ...

So no, I don't see how this can easily be achieved.


cheers,
Lukas

Re: Configuring HAproxy to Mbed tls implementation of TLS

[Lukas Tribus]

Hello,


On 1 February 2018 at 03:13, Mariam Abboush  wrote:
> Hello dear HAproxy stuff
>
>
> How can I configure HAproxy to a specific implementation of TLS, I mean for
> example " Mbed TLS" which is a security library dedicated to the embedded
> systems.

You can't.

Haproxy supports OpenSSL, and we try to make it work with OpenSSL
forks like LibreSSL and boringssl, but a different library is not
supported.



Lukas