copy paper of A4 size

2017-12-21 Thread Jane 


Dear Sir,
 
Here recommand our popular products as below:
 
1. A4 copy paper
2. Newsprint paper
3. Offset paper
4. Coated paper
5. Carbonless paper


Please select the type you are most interested in and we will send the 
quotations.
 
Waiting for your kind response.


Regards
Judy






 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 





 




【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

2017-12-21 Thread Willy Tarreau 
On Fri, Dec 22, 2017 at 12:34:45AM +0100, Cyril Bonté wrote:
> And after performing the same tests with the patch applied, I can confirm I
> don't reproduce the issue anymore ;-)

Cool, thanks for your feedback Cyril!
Willy

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

2017-12-21 Thread Cyril Bonté 

Hi all,

Le 21/12/2017 à 15:25, Willy Tarreau a écrit :

On Thu, Dec 21, 2017 at 02:53:07PM +0100, Emeric Brun wrote:

Hi All,

This bug should be fixed using this patch (patch on dev, abd should be 
backported in 1.8).


now applied to both branches,, thanks!
Willy


And after performing the same tests with the patch applied, I can 
confirm I don't reproduce the issue anymore ;-)


--
Cyril Bonté

Freelance Work

2017-12-21 Thread Brian Clark 

 Hi Kai, 
 I'm Brian. I found you at lautaportti.wordpress.com and wanted to reach out to 
see if you ever take on any freelance dev work? If you do then I'd like to 
invite you to join our curated freelance network LocalSolo. 
 We aren't a big funded startup, we're just a small team of working freelancers 
ourselves. However we have hundreds of legit companies looking for quality 
freelance devs on our network. 
 You work directly with any clients you make contact with on our network, we 
don't take a cut or get involved. And we encourage you to charge the rate you 
deserve. 
 If you're interested, here's a link to bypass our regular application queue: 
 https://localsolo.com/signup/vip/devs/ 
 Let me know if you have any questions at all. 
 Cheers, 
 Brian 
 
 LocalSolo Freelance PO Box 20025 Fairview PO, Vancouver, BC V5Z 0C1, Canada 
 This is the only email I'll be sending you. But here's the "Don't bother me 
again" link if you'd like to make sure.

Re: Issue after upgrade from 1.7 to 1.8 related with active sessions

2017-12-21 Thread Ricardo Fraile 
Well, I isolate the service on a load balancer server with the minimal
configuration, let me detail the problem.

Two equal (cloned) Debian load balancers with 3.16.7-ckt9 kernel, both
working with keepalived sharing the ip address of the proxy-tcp service
(192.168.1.100). In A server the Haproxy is v.1.8.1 and in B v.1.7.4,
both have the following configuration (only in 1.7 the "master-worker"
line is removed):

global
master-worker
node balancer
log /dev/log local1 info
stats socket /var/run/haproxy.sock mode 0660 user testuser1
group testuser1 level admin
pidfile /var/run/haproxy.pid
maxconn 32000
nbproc 1

defaults
modetcp
log global
retries 3
option redispatch

maxconn 10
fullconn 10

timeout connect  5s
timeout server   50s
timeout client   50s
timeout http-keep-alive  60s

default-server on-marked-down shutdown-sessions inter 5s
fastinter 1s downinter 1s rise 2 fall 2

listen proxy-stats
bind *:80
mode http
stats enable
stats show-legends
stats uri /
stats realm   Haproxy\ Statistics
stats refresh 5s

listen proxy-tcp
bind 192.168.1.100:8080
option tcplog
balance roundrobin

option httpchk GET /test
http-check expect string ok

server server1 192.168.1.101:8080 check
server server2 192.168.1.102:8080 check


After changing the traffic between both servers with keepalived, the
results are:

1.7:
Session rate: 861
Sessions: 220

1.8:
Session rate: 835
Sessions: 31243

These are the evidences in 1.8 server:

- The ulimit-n is 64034 and the Sessions Max reach 31999 both in
Frontend and Backend of the lister proxy-tcp, which I suppose that the
limit is reached by consequence of the issue.

- The system log report a lot of "TCP: too many orphaned sockets" and
some like "net_ratelimit: 2094 callbacks suppressed"

- The Haproxy log register the total time elapsed between the accept and
the last close is equal to the 50s assigned to server and client
timeout.

- The termination state is ok in 99% of them. Yesterday I said that it
was "sD", but today I check that is very rare, I put one line here only
as example.

Dec 21 15:38:09 balancer haproxy[8094]: 192.168.1.55:58674
[21/Dec/2017:15:37:19.358] proxy-tcp proxy-tcp/server2 1/0/50001 1087 --
30211/30210/30209/15106/0 0/0
Dec 21 15:38:09 balancer haproxy[8094]: 192.168.1.42:51027
[21/Dec/2017:15:37:19.356] proxy-tcp proxy-tcp/server2 1/0/50008 5345 sD
30214/30213/30210/15106/0 0/0
Dec 21 15:38:09 balancer haproxy[8094]: 192.168.1.55:40442
[21/Dec/2017:15:37:19.364] proxy-tcp proxy-tcp/server1 1/0/50003 694 --
30216/30215/30211/15104/0 0/0

- From 30522 tcp sockets to the proxy-tcp address, there are 30160 in
CLOSE_WAIT state over local address 192.168.1.100:8080. Yesterday I
point that it was from the backend side, but I'm wrong, all are from the
fronted side.


I have the ouput of "show sess all" and "show fd", but as it have a lot
of private information, I send you using an alternative way. If there
are any clear evidence there, I will take the time to anonymize and
share.


Thanks,

El mié, 20-12-2017 a las 18:19 +0100, Willy Tarreau escribió:
> Hello Ricardo,
> 
> On Wed, Dec 20, 2017 at 05:00:33PM +0100, Ricardo Fraile wrote:
> > Hello,
> > 
> > After upgrade from 1.7.4 to 1.8.1, basically with the end of mail conf
> > snippet, the sessions started to grow, as example:
> > 
> > 1.7.4:
> > Active sessions: ~161
> > Active sessions rate: ~425
> > 
> > 1.8.1:
> > Active sessions: ~6700
> > Active sessions rate: ~350
> 
> Ah that's not good :-(
> 
> > Looking into the linux (3.16.7) server, there are a high number of
> > CLOSE_WAIT connections from the bind address of the listen service to
> > the backend nodes.
> 
> Strange, I don't understand well what type of traffic could cause this
> except a loop, that sounds a bit unusual.
> 
> > System logs reported "TCP: too many orphaned sockets", but after
> > increase net.ipv4.tcp_max_orphans value, the message stops but nothing
> > changes.
> 
> Normally orphans correspond to closed sockets for which there are still
> data in the system's buffers so this should be unrelated to the CLOSE_WAIT,
> unless there's a loop somewhere where a backend reconnects to the frontend,
> which can explain both situations at once when the timeout strikes.
> 
> > Haproxy logs reported for that listen the indicator "sD", but only with
> > 1.8.
> 
> Thus a server timeout during the end of the transfer. That doesn't make
> much sense either.
> 
> > Any ideas to dig into the issue?
> 
> It would be very useful that you share your configuration (please remove
> any sensitive info like stats passwords or IP addresses you prefer to keep
> private). When running 1.8, it would be useful to issue the following
> commands on the CLI and capture the

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

2017-12-21 Thread Willy Tarreau 
On Thu, Dec 21, 2017 at 02:53:07PM +0100, Emeric Brun wrote:
> Hi All,
> 
> This bug should be fixed using this patch (patch on dev, abd should be 
> backported in 1.8).

now applied to both branches,, thanks!
Willy

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

2017-12-21 Thread Bertrand Jacquin 


On 21/12/17 13:28, Willy Tarreau wrote:
> On Thu, Dec 21, 2017 at 10:46:17AM +, Bertrand Jacquin wrote:
>> I'm all good with backporting this in 1.8. Feel free to.
> 
> Great, now merged. Do not hesitate to report back any issues you
> would notice on your infrastructure.

Thanks Willy, sure I will!

-- 
Bertrand




signature.asc
Description: OpenPGP digital signature
Amazon Data Services Ireland Limited registered office: One Burlington Plaza, 
Burlington Road, Dublin 4, Ireland. Registered in Ireland. Registration number 
390566.

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

2017-12-21 Thread Emeric Brun 
Hi All,

This bug should be fixed using this patch (patch on dev, abd should be 
backported in 1.8).

R,
Emeric

On 12/21/2017 10:42 AM, Greg Nolle wrote:
> Thanks guys! I should be able to test the new version this weekend if you are 
> able to issue it before then.
> 
> Best regards,
> Greg
> 
> On Thu, Dec 21, 2017 at 12:15 AM, Willy Tarreau  > wrote:
> 
> On Thu, Dec 21, 2017 at 12:04:11AM +0100, Cyril Bonté wrote:
> > Hi Greg,
> >
> > Le 20/12/2017 à 22:42, Greg Nolle a écrit :
> > > Hi Andrew,
> > >
> > > Thanks for the info but I'm afraid I'm not seeing anything here that
> > > would affect the issue I'm seeing, and by the way the docs don't
> > > indicate that the cookie names have to match the server names.
> >
> > First, don't worry about the configuration, there is nothing wrong in 
> it ;-)
> >
> > > That being said, I tried using your settings and am still seeing the
> > > issue (see below for new full config). And like I say, this is only an
> > > issue with v1.8.1, it works as expected in v1.7.9.
> >
> > I won't be able to look further tonight, but at least I could identify 
> when
> > the regression occured : it's caused by the work done to prepare
> > multi-threading, more specifically by this commit :
> > http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=64cc49cf7 
> 
> >
> > I add Emeric to the thread, maybe he'll be able to provide a fix faster 
> than
> > me (I'll won't be very available for the next days).
> 
> Thus I'll ping Emeric tomorrow as well so that we can issue 1.8.2 soon in
> case someone wants to play with it on friday afternoon jus before xmas :-)
> 
> Willy
> 
> 

>From db483435c294541cbab27babacb9daefc043fd32 Mon Sep 17 00:00:00 2001
From: Emeric Brun 
Date: Thu, 21 Dec 2017 14:42:26 +0100
Subject: [PATCH] BUG/MEDIUM: checks: a server passed in maint state was not
 forced down.

Setting a server in maint mode, the required next_state was not set
before calling the 'lb_down' function and so the system state was never
commited.

This patch should be backported in 1.8
---
 src/server.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/server.c b/src/server.c
index 23e4cc9..a37e919 100644
--- a/src/server.c
+++ b/src/server.c
@@ -4630,10 +4630,11 @@ void srv_update_status(struct server *s)
 		else {	/* server was still running */
 			check->health = 0; /* failure */
 			s->last_change = now.tv_sec;
+
+			s->next_state = SRV_ST_STOPPED;
 			if (s->proxy->lbprm.set_server_status_down)
 s->proxy->lbprm.set_server_status_down(s);
 
-			s->next_state = SRV_ST_STOPPED;
 			if (s->onmarkeddown & HANA_ONMARKEDDOWN_SHUTDOWNSESSIONS)
 srv_shutdown_streams(s, SF_ERR_DOWN);
 
-- 
2.7.4

[PATCH] MINOR: lua: fix crash when using bogus mode in register_service()

2017-12-21 Thread Eric Salama 

HAProxy crashes when one use a bogus mode with core.register_service().
The 2nd argument must be "http" or "tcp", but any other value crashes 
HAProxy

when it displays the error message.

To reproduce:

haproxy.cfg:

global
    lua-load crash.lua


crash.lua:
function f() end
core.register_service("lua_svc", "bogus_mode", f);


The fix is attached.

>From ad97c5d05a1cf06bca1a3e99a33d55c51035f6b5 Mon Sep 17 00:00:00 2001
From: Eric Salama 
Date: Thu, 21 Dec 2017 14:30:07 +0100
Subject: [PATCH] MINOR: lua: fix crash when using bogus mode in
 register_service()

When using an incorrect 'mode' as 2nd argument of core.register_service(),
HAProxy crashes while displaying the error message.
---
 src/hlua.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/hlua.c b/src/hlua.c
index 2c28e673..abd096d0 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -6871,7 +6871,7 @@ __LJMP static int hlua_register_service(lua_State *L)
 		akl->kw[0].parse = action_register_service_http;
 	else
 		WILL_LJMP(luaL_error(L, "lua service environment '%s' is unknown. "
-		"'tcp' or 'http' are expected."));
+		"'tcp' or 'http' are expected.", env));
 
 	akl->kw[0].match_pfx = 0;
 	akl->kw[0].private = fcn;
-- 
2.14.2

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

2017-12-21 Thread Willy Tarreau 
On Thu, Dec 21, 2017 at 10:46:17AM +, Bertrand Jacquin wrote:
> I'm all good with backporting this in 1.8. Feel free to.

Great, now merged. Do not hesitate to report back any issues you
would notice on your infrastructure.

cheers,
Willy

Re: 1.8.1 Segfault + slowdown

2017-12-21 Thread Christopher Faulet 

Le 21/12/2017 à 08:42, Peter Lindegaard Hansen a écrit :

update:

we've disabled h2 on 1.8, and everything is running as expected again. 
haproxy does not degrade performance anymore nor does it segfault.

so it issues seem to be related to the h2



Med venlig hilsen


*Peter Lindegaard Hansen*
/Softwareudvikler / Partner
/

Telefon: +45 96 500 300 | Direkte: 69 14 97 04 | Email: 
p...@tigermedia.dk 
Tiger Media A/S | Gl. Gugvej 17C | 9000 Aalborg | Web: www.tigermedia.dk 



For supportspørgsmål kontakt os da på supp...@tigermedia.dk 
 eller på tlf. 96 500 300

og din henvendelse vil blive besvaret af første ledige medarbejder.


2017-12-19 11:36 GMT+01:00 Peter Lindegaard Hansen >:


Hi list,

We upgraded from 1.5 to 1.8 recently - then to 1.8.1

Now we're seeing segfaults and slowdowns with haproxy

Repeating:
Dec 19 11:14:26 haproxy02 kernel: [122635.295196] haproxy[29582]:
segfault at 55d5152279b2 ip 7f9c2dcc5a28 sp 7fff07caf4b8
error 6 in libc-2.23.so [7f9c2dc26000+1c]
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Main process
exited, code=exited, status=139/n/a
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Unit entered
failed state.
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Failed with
result 'exit-code'.
Dec 19 11:14:26 haproxy02 systemd[1]: haproxy.service: Service
hold-off time over, scheduling restart.
Dec 19 11:14:26 haproxy02 systemd[1]: Stopped HAProxy Load Balancer.
Dec 19 11:14:26 haproxy02 systemd[1]: Starting HAProxy Load Balancer...
Dec 19 11:14:26 haproxy02 systemd[1]: Started HAProxy Load Balancer.
Dec 19 11:14:27 haproxy02 kernel: [122636.578738] haproxy[31479]:
segfault at 56409a8c1de2 ip 7fa5fa349a28 sp 7ffe66f4f688
error 6 in libc-2.23.so [7fa5fa2aa000+1c]
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Main process
exited, code=exited, status=139/n/a
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Unit entered
failed state.
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Failed with
result 'exit-code'.
Dec 19 11:14:27 haproxy02 systemd[1]: haproxy.service: Service
hold-off time over, scheduling restart.
Dec 19 11:14:27 haproxy02 systemd[1]: Stopped HAProxy Load Balancer.
Dec 19 11:14:27 haproxy02 systemd[1]: Starting HAProxy Load Balancer...
Dec 19 11:14:28 haproxy02 systemd[1]: Started HAProxy Load Balancer.
Dec 19 11:14:28 haproxy02 kernel: [122637.569863] haproxy[31487]:
segfault at 55cb4bd59857 ip 7f71e678aa28 sp 7fffb94427b8
error 6 in libc-2.23.so [7f71e66eb000+1c]
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Main process
exited, code=exited, status=139/n/a
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Unit entered
failed state.
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Failed with
result 'exit-code'.
Dec 19 11:14:28 haproxy02 systemd[1]: haproxy.service: Service
hold-off time over, scheduling restart.
Dec 19 11:14:28 haproxy02 systemd[1]: Stopped HAProxy Load Balancer.
Dec 19 11:14:28 haproxy02 systemd[1]: Starting HAProxy Load Balancer...
Dec 19 11:14:29 haproxy02 systemd[1]: Started HAProxy Load Balancer.


At same time in haproxy.log

(lots of ssl handshake failures...) then
Dec 19 11:14:26 haproxy02 haproxy[29579]: [ALERT] 352/090058 (29579)
: Current worker 29582 left with exit code 139
Dec 19 11:14:26 haproxy02 haproxy[29579]: [ALERT] 352/090058 (29579)
: exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:26 haproxy02 haproxy[29579]: [WARNING] 352/090058
(29579) : All workers are left. Leaving... (139)
Dec 19 11:14:27 haproxy02 haproxy[31476]: [ALERT] 352/111426 (31476)
: Current worker 31479 left with exit code 139
Dec 19 11:14:27 haproxy02 haproxy[31476]: [ALERT] 352/111426 (31476)
: exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:27 haproxy02 haproxy[31476]: [WARNING] 352/111426
(31476) : All workers are left. Leaving... (139)
Dec 19 11:14:28 haproxy02 haproxy[31485]: [ALERT] 352/111428 (31485)
: Current worker 31487 left with exit code 139
Dec 19 11:14:28 haproxy02 haproxy[31485]: [ALERT] 352/111428 (31485)
: exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:28 haproxy02 haproxy[31485]: [WARNING] 352/111428
(31485) : All workers are left. Leaving... (139)
Dec 19 11:14:29 haproxy02 haproxy[31493]: [ALERT] 352/111429 (31493)
: Current worker 31496 left with exit code 139
Dec 19 11:14:29 haproxy02 haproxy[31493]: [ALERT] 352/111429 (31493)
: exit-on-failure: killing every workers with SIGTERM
Dec 19 11:14:29 haproxy02

AW: HTTP/2 Termination vs. Firefox Quantum

2017-12-21 Thread Maximilian Böhm 
You are right.

We've followed this manual: 
https://haproxy.debian.net/#?distribution=Debian=jessie=1.8

 # haproxy -vv
HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 
USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_NS=1

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

Built with OpenSSL version : OpenSSL 1.0.2l  25 May 2017
Running on OpenSSL version : OpenSSL 1.0.2l  25 May 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.35 2014-04-04
Running on PCRE version : 8.35 2014-04-04
PCRE library supports JIT : yes
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with network namespace 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 filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace







-Ursprüngliche Nachricht-
Von: Vincent Bernat [mailto:ber...@luffy.cx] 
Gesendet: Donnerstag, 21. Dezember 2017 11:04
An: Maximilian Böhm 
Cc: haproxy@formilux.org
Betreff: Re: HTTP/2 Termination vs. Firefox Quantum

 ❦ 21 décembre 2017 09:00 GMT, Maximilian Böhm  :

> We are using HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04 on Debian 8. On the 
> backend, jetty 9.3.11.v20160721 with http/1.1 answers requests.
>
> Since I've enabled http/2 ("alpn h2,http/1.1"), we are facing issues with 
> Firefox Quantum both, on windows 10 and macOS. I do not have any complaints 
> regarding other browsers (yet?). Requested HTML pages are delivered empty or 
> even cut in the middle. There is no recurring pattern, it's like a lottery, 
> still, very seldom.. The yet simple but not satisfiable solution is to 
> restart the browser.
>
> I know the provided information is quite spare, so my question is
> actually, if there Is there any guideline I can follow to provide you
> more information? I've appended some snippets of the proxy
> configuration.

Also provide "haproxy -vv". I believe in your case, this is:

HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 
USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_NS=1

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

Built with OpenSSL version : OpenSSL 1.0.2l  25 May 2017
Running on OpenSSL version : OpenSSL 1.0.2l  25 May 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.35 2014-04-04
Running on PCRE version : 8.35 2014-04-04
PCRE library supports JIT : yes
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with network namespace 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 filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

2017-12-21 Thread Bertrand Jacquin 
Hi Willy,

On 21/12/17 10:08, Willy Tarreau wrote:
> On Thu, Dec 21, 2017 at 11:05:30AM +0100, Andreas Mahnke wrote:
>> Hi Willy,
>>
>> The support of the standard protocol in 1.8 would be nice, because we are
>> planning to migrate to haproxy 1.8 from our self - patched 1.7 instances.
> 
> OK. Bertrand, if you don't scream quickly, I'll pick your patches in 1.8 :-)

I'm all good with backporting this in 1.8. Feel free to.

Cheers,
Bertrand

-- 
Bertrand



signature.asc
Description: OpenPGP digital signature
Amazon Data Services Ireland Limited registered office: One Burlington Plaza, 
Burlington Road, Dublin 4, Ireland. Registered in Ireland. Registration number 
390566.

Re:Re: 回复：Haproxy SSl Termination performance issue

2017-12-21 Thread Mike G 



Hi,  Emeric


got it.


Thanks a lot




Mike








At 2017-12-21 18:19:50, "Emeric Brun"  wrote:
>Hi Mike,
>
>Thierry is right, 4096 rsa key computation have clearly an heavy CPU cost.
>In our internal benchmark we notice:
>Using one process of haproxy on one core of i7-4790K CPU @ 4.00GHz we reach 
>170 con/s (comparatively 1350 con/s using 2048 rsa key).
>
>Usually this CPU usage isn't so high because software clients use "session ID" 
>or "tls tickets" witch avoid to recompute an rsa key for each new connection 
>from the same client.
>
>I don't know if what you observe is due to a production traffic or a benchmark 
>tool but in any case your software clients
>don't seem to reuse sessions.
>
>Anyway, Thierry has well described how to scale your arch using the max of 
>available cpu.
>
>R,
>Emeric 
> 
>
>
>On 12/19/2017 04:14 PM, hongw...@163.com wrote:
>> Hi, Thierry.
>> 
>> Thanks again.
>> 
>> One more question about you talking about, can i just think like this way: 
>> assume we got a 8core cpu, we use 7 of them for ssl termination and one is 
>> for http forward? If it is, is there any document for this soulution?
>> 
>> Thanks a lot
>> 
>> Mike
>> 
>> 
>> 
>>  原始邮件 
>> 主题：Re: Haproxy SSl Termination performance issue
>> 发件人：Thierry Fournier
>> 收件人：Mike G
>> 抄送：Haproxy
>> 
>> 
>> Ok, you’re using HAProxy as SSL offloading. HAProxy is one of the
>> right solutions for doing this. You’re performance problem is not
>> due to HAProxy, each component using OpenSSL will reach the same
>> limits.
>> 
>> Classic setup is to configure many process for the SSL offloading
>> (proxy in TCP mode), and only one for the HTTP. This setup works
>> fine because it allow many CPU for the SSL which require computing,
>> and the HTTP processing is done by only one process which can
>> perform accounting and apply limits (rate limit, connexion limit,
>> ...).
>> 
>> Thierry
>> 
>> 
>> > On 19 Dec 2017, at 12:44, Mike G wrote:
>> >
>> >
>> >
>> > Hi, Thierry.
>> >
>> > our case is like this: we put a haproxy as ssl termination. and 
>> haproxy got the https requirement. and then go throught SSL ternimation. and 
>> then forward
>> > the request to web (by HTTP), also, get the Http request and encrypt 
>> it, and return HTTPS to client.
>> >
>> >
>> > thanks
>> >
>> > Mike
>> >
>> >
>> >
>> >
>> >
>> > At 2017-12-19 19:25:09, "Thierry Fournier" wrote:
>> > >Hi,
>> > >
>> > >What kind of job ?
>> > >
>> > >Thierry
>> > >
>> > >> On 19 Dec 2017, at 12:17, hongw...@163.com wrote:
>> > >>
>> > >> Hi，Thierry
>> > >>
>> > >> got it. Thanks！
>> > >>
>> > >> By the way, may I ask the ssl termination is best solution for this 
>> kind of job?
>> > >>
>> > >>
>> > >> Many thanks
>> > >>
>> > >> Mike
>> > >>
>> > >>
>> > >>
>> > >>  原始邮件 
>> > >> 主题：Re: Haproxy SSl Termination performance issue
>> > >> 发件人：Thierry Fournier
>> > >> 收件人：Mike G
>> > >> 抄送：Haproxy
>> > >>
>> > >>
>> > >> Hi,
>> > >>
>> > >> I gues that 130 is 130 SSL requests per seconds ?
>> > >>
>> > >> SSL is a very heavy processing. The 4096 bits certificates consume 
>> more
>> > >> CPU that 2048 (thanks captain obvious). Your capacity processing is
>> > >> capped by your CPU. You must check the CPU of your server during 
>> your
>> > >> test. If the CPU consummation is 100%, you reach the limit of your 
>> server.
>> > >>
>> > >> If you reach the limit of one CPU (nbproc), you can use more CPU 
>> and/or more
>> > >> servers.
>> > >>
>> > >> Thierry
>> > >>
>> > >>
>> > >> > On 19 Dec 2017, at 08:36, Mike G wrote:
>> > >> >
>> > >> > Hi, everyone.
>> > >> >
>> > >> > I just got a problem about the haproxy ssl termination 
>> performance issues.
>> > >> > we have a case which want to use SSL Termination. so, we did some 
>> testing before online, I know the virtual machine will not good choice, but 
>> it make feel so supriose the cur link can be more than 130 when I use 4096 
>> key.
>> > >> > here's my configuration about the haproxy:
>> > >> >
>> > >> > haproxy as SSL termination layer before web server.
>> > >> > the haproxy version is 1.8.1
>> > >> > I compile it by myself:
>> > >> > use the parameter:
>> > >> > make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
>> > >> >
>> > >> > also, I use download openssl 1.0.2n from openssl.org, and compile 
>> by those parameters:
>> > >> > ./config -d zlib
>> > >> >
>> > >> > after install openssl and haproxy.
>> > >> > here's my configuration about the haproxy:
>> > >> > global
>> > >> > log 127.0.0.1 local0
>> > >> >
>> > >> > chroot /var/lib/haproxy
>> > >> > pidfile

Re: 回复：Haproxy SSl Termination performance issue

2017-12-21 Thread Emeric Brun 
Hi Mike,

Thierry is right, 4096 rsa key computation have clearly an heavy CPU cost.
In our internal benchmark we notice:
Using one process of haproxy on one core of i7-4790K CPU @ 4.00GHz we reach 170 
con/s (comparatively 1350 con/s using 2048 rsa key).

Usually this CPU usage isn't so high because software clients use "session ID" 
or "tls tickets" witch avoid to recompute an rsa key for each new connection 
from the same client.

I don't know if what you observe is due to a production traffic or a benchmark 
tool but in any case your software clients
don't seem to reuse sessions.

Anyway, Thierry has well described how to scale your arch using the max of 
available cpu.

R,
Emeric 
 


On 12/19/2017 04:14 PM, hongw...@163.com wrote:
> Hi, Thierry.
> 
> Thanks again.
> 
> One more question about you talking about, can i just think like this way: 
> assume we got a 8core cpu, we use 7 of them for ssl termination and one is 
> for http forward? If it is, is there any document for this soulution?
> 
> Thanks a lot
> 
> Mike
> 
> 
> 
>  原始邮件 
> 主题：Re: Haproxy SSl Termination performance issue
> 发件人：Thierry Fournier
> 收件人：Mike G
> 抄送：Haproxy
> 
> 
> Ok, you’re using HAProxy as SSL offloading. HAProxy is one of the
> right solutions for doing this. You’re performance problem is not
> due to HAProxy, each component using OpenSSL will reach the same
> limits.
> 
> Classic setup is to configure many process for the SSL offloading
> (proxy in TCP mode), and only one for the HTTP. This setup works
> fine because it allow many CPU for the SSL which require computing,
> and the HTTP processing is done by only one process which can
> perform accounting and apply limits (rate limit, connexion limit,
> ...).
> 
> Thierry
> 
> 
> > On 19 Dec 2017, at 12:44, Mike G wrote:
> >
> >
> >
> > Hi, Thierry.
> >
> > our case is like this: we put a haproxy as ssl termination. and haproxy 
> got the https requirement. and then go throught SSL ternimation. and then 
> forward
> > the request to web (by HTTP), also, get the Http request and encrypt 
> it, and return HTTPS to client.
> >
> >
> > thanks
> >
> > Mike
> >
> >
> >
> >
> >
> > At 2017-12-19 19:25:09, "Thierry Fournier" wrote:
> > >Hi,
> > >
> > >What kind of job ?
> > >
> > >Thierry
> > >
> > >> On 19 Dec 2017, at 12:17, hongw...@163.com wrote:
> > >>
> > >> Hi，Thierry
> > >>
> > >> got it. Thanks！
> > >>
> > >> By the way, may I ask the ssl termination is best solution for this 
> kind of job?
> > >>
> > >>
> > >> Many thanks
> > >>
> > >> Mike
> > >>
> > >>
> > >>
> > >>  原始邮件 
> > >> 主题：Re: Haproxy SSl Termination performance issue
> > >> 发件人：Thierry Fournier
> > >> 收件人：Mike G
> > >> 抄送：Haproxy
> > >>
> > >>
> > >> Hi,
> > >>
> > >> I gues that 130 is 130 SSL requests per seconds ?
> > >>
> > >> SSL is a very heavy processing. The 4096 bits certificates consume 
> more
> > >> CPU that 2048 (thanks captain obvious). Your capacity processing is
> > >> capped by your CPU. You must check the CPU of your server during your
> > >> test. If the CPU consummation is 100%, you reach the limit of your 
> server.
> > >>
> > >> If you reach the limit of one CPU (nbproc), you can use more CPU 
> and/or more
> > >> servers.
> > >>
> > >> Thierry
> > >>
> > >>
> > >> > On 19 Dec 2017, at 08:36, Mike G wrote:
> > >> >
> > >> > Hi, everyone.
> > >> >
> > >> > I just got a problem about the haproxy ssl termination performance 
> issues.
> > >> > we have a case which want to use SSL Termination. so, we did some 
> testing before online, I know the virtual machine will not good choice, but 
> it make feel so supriose the cur link can be more than 130 when I use 4096 
> key.
> > >> > here's my configuration about the haproxy:
> > >> >
> > >> > haproxy as SSL termination layer before web server.
> > >> > the haproxy version is 1.8.1
> > >> > I compile it by myself:
> > >> > use the parameter:
> > >> > make TARGET=linux2628 USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1
> > >> >
> > >> > also, I use download openssl 1.0.2n from openssl.org, and compile 
> by those parameters:
> > >> > ./config -d zlib
> > >> >
> > >> > after install openssl and haproxy.
> > >> > here's my configuration about the haproxy:
> > >> > global
> > >> > log 127.0.0.1 local0
> > >> >
> > >> > chroot /var/lib/haproxy
> > >> > pidfile /var/run/haproxy.pid
> > >> > maxconn 65535
> > >> > group haproxy
> > >> > user haproxy
> > >> > daemon
> > >> > nbproc 1
> > >> >
> > >> > stats socket /var/lib/haproxy/stats
> > >> > tune.ssl.default-dh-param 2048
> > >> >
> > >> > defaults
>

Re: Certificate bundles seem to be non-functional

2017-12-21 Thread Christopher Faulet 

Le 20/12/2017 à 02:44, Andrew Heberle a écrit :
I am attempting to utilise certificate bundles so we can have multi-type 
certs in haproxy however this seems non-functional.


I have a two cert bundles as follows (only testing with RSA certs at the 
moment):


/etc/haproxy/ssl # ls -l /etc/haproxy/ssl/
total 16
-rw-r--r-- 1 root root 1184 Dec 20 01:39 test1.pem.issuer.rsa
-rw-r--r-- 1 root root 2888 Dec 20 01:26 test1.pem.rsa
-rw-r--r-- 1 root root 1184 Dec 20 01:40 test2.pem.issuer.rsa
-rw-r--r-- 1 root root 2888 Dec 20 01:30 test2.pem.rsa

With the following config of my two front-ends:

frontend test1
     bind *:5000 ssl crt test1.pem
     default_backend app1

frontend test2
     bind *:5001 ssl crt test2.pem
     default_backend app2

But this then fails:

/etc/haproxy/ssl # haproxy -f /etc/haproxy/haproxy.cfg -c
[ALERT] 353/014339 (59) : parsing [/etc/haproxy/haproxy.cfg:34] : 'bind 
*:5000' : unable to stat SSL certificate from fi

le '/etc/haproxy/ssl/test1.pem' : No such file or directory.
[ALERT] 353/014339 (59) : parsing [/etc/haproxy/haproxy.cfg:38] : 'bind 
*:5001' : unable to stat SSL certificate from fi

le '/etc/haproxy/ssl/test2.pem' : No such file or directory.
[ALERT] 353/014339 (59) : Error(s) found in configuration file : 
/etc/haproxy/haproxy.cfg

[ALERT] 353/014339 (59) : Fatal errors found in configuration.

Build Options:

HA-Proxy version 1.7.9 2017/08/18
Copyright 2000-2017 Willy Tarreau >


Build options :
   TARGET  = linux2628
   CPU     = generic
   CC      = gcc
   CFLAGS  = -Os -fomit-frame-pointer
   OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1

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

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), 
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")

Built with OpenSSL version : LibreSSL 2.6.3
Running on OpenSSL version : LibreSSL 2.6.3
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.41 2017-07-05
Running on PCRE version : 8.41 2017-07-05
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Built with Lua version : Lua 5.3.4
Built with transparent proxy support using: IP_TRANSPARENT 
IPV6_TRANSPARENT IP_FREEBIND


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 filters :
         [COMP] compression
         [TRACE] trace
         [SPOE] spoe



Hi,

LibreSSL is API compatible with OpenSSL 1.0.1. So it does not support 
multiple certificates for the same CN. It only works for OpenSSL >= 
1.0.2. However, the error message is misleading.


--
Christopher

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

2017-12-21 Thread Willy Tarreau 
On Thu, Dec 21, 2017 at 11:05:30AM +0100, Andreas Mahnke wrote:
> Hi Willy,
> 
> The support of the standard protocol in 1.8 would be nice, because we are
> planning to migrate to haproxy 1.8 from our self - patched 1.7 instances.

OK. Bertrand, if you don't scream quickly, I'll pick your patches in 1.8 :-)

Willy

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

2017-12-21 Thread Andreas Mahnke 
Hi Willy,

The support of the standard protocol in 1.8 would be nice, because we are
planning to migrate to haproxy 1.8 from our self - patched 1.7 instances.

Regards,
Andreas



On Thu, Dec 21, 2017 at 10:57 AM, Willy Tarreau  wrote:

> Bertrand, Andreas,
>
> The NS CIP fixes were backported to 1.8. Initially I was not considering
> backporting your latest changes to support the new version of the protocol
> since it's a feature addition. But now that I'm thinking about it, the
> change is minimal and very well isolated and you very likely are the two
> only users of this feature, so even if it would break anything it would
> be your problem :-)  Thus my question is simple : do you *need* support
> of the standard protocol support in 1.8 or not, and is any of you against
> the backport if the other one needs it ?
>
> Please just le me know.
>
> Thanks,
> Willy
>

Re: HTTP/2 Termination vs. Firefox Quantum

2017-12-21 Thread Vincent Bernat 
 ❦ 21 décembre 2017 09:00 GMT, Maximilian Böhm  :

> We are using HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04 on Debian 8. On the 
> backend, jetty 9.3.11.v20160721 with http/1.1 answers requests.
>
> Since I've enabled http/2 ("alpn h2,http/1.1"), we are facing issues with 
> Firefox Quantum both, on windows 10 and macOS. I do not have any complaints 
> regarding other browsers (yet?). Requested HTML pages are delivered empty or 
> even cut in the middle. There is no recurring pattern, it's like a lottery, 
> still, very seldom.. The yet simple but not satisfiable solution is to 
> restart the browser.
>
> I know the provided information is quite spare, so my question is
> actually, if there Is there any guideline I can follow to provide you
> more information? I've appended some snippets of the proxy
> configuration.

Also provide "haproxy -vv". I believe in your case, this is:

HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04
Copyright 2000-2017 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -O2 -fPIE -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_LUA=1 
USE_SYSTEMD=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_NS=1

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

Built with OpenSSL version : OpenSSL 1.0.2l  25 May 2017
Running on OpenSSL version : OpenSSL 1.0.2l  25 May 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Encrypted password support via crypt(3): yes
Built with multi-threading support.
Built with PCRE version : 8.35 2014-04-04
Running on PCRE version : 8.35 2014-04-04
PCRE library supports JIT : yes
Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with network namespace 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 filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace
-- 
Each module should do one thing well.
- The Elements of Programming Style (Kernighan & Plauger)

Re: [PATCH] BUG: NetScaler CIP handling is incorrect

2017-12-21 Thread Willy Tarreau 
Bertrand, Andreas,

The NS CIP fixes were backported to 1.8. Initially I was not considering
backporting your latest changes to support the new version of the protocol
since it's a feature addition. But now that I'm thinking about it, the
change is minimal and very well isolated and you very likely are the two
only users of this feature, so even if it would break anything it would
be your problem :-)  Thus my question is simple : do you *need* support
of the standard protocol support in 1.8 or not, and is any of you against
the backport if the other one needs it ?

Please just le me know.

Thanks,
Willy

Re: Traffic delivered to disabled server when cookie persistence is enabled after upgrading to 1.8.1

2017-12-21 Thread Greg Nolle 
Thanks guys! I should be able to test the new version this weekend if you
are able to issue it before then.

Best regards,
Greg

On Thu, Dec 21, 2017 at 12:15 AM, Willy Tarreau  wrote:

> On Thu, Dec 21, 2017 at 12:04:11AM +0100, Cyril Bonté wrote:
> > Hi Greg,
> >
> > Le 20/12/2017 à 22:42, Greg Nolle a écrit :
> > > Hi Andrew,
> > >
> > > Thanks for the info but I'm afraid I'm not seeing anything here that
> > > would affect the issue I'm seeing, and by the way the docs don't
> > > indicate that the cookie names have to match the server names.
> >
> > First, don't worry about the configuration, there is nothing wrong in it
> ;-)
> >
> > > That being said, I tried using your settings and am still seeing the
> > > issue (see below for new full config). And like I say, this is only an
> > > issue with v1.8.1, it works as expected in v1.7.9.
> >
> > I won't be able to look further tonight, but at least I could identify
> when
> > the regression occured : it's caused by the work done to prepare
> > multi-threading, more specifically by this commit :
> > http://git.haproxy.org/?p=haproxy.git;a=commitdiff;h=64cc49cf7
> >
> > I add Emeric to the thread, maybe he'll be able to provide a fix faster
> than
> > me (I'll won't be very available for the next days).
>
> Thus I'll ping Emeric tomorrow as well so that we can issue 1.8.2 soon in
> case someone wants to play with it on friday afternoon jus before xmas :-)
>
> Willy
>

HTTP/2 Termination vs. Firefox Quantum

2017-12-21 Thread Maximilian Böhm 
Hi there,

thanks for releasing support for http/2! Sadly, we are facing issues since 
enabling it.

We are using HA-Proxy version 1.8.1-1~bpo8+1 2017/12/04 on Debian 8. On the 
backend, jetty 9.3.11.v20160721 with http/1.1 answers requests.

Since I've enabled http/2 ("alpn h2,http/1.1"), we are facing issues with 
Firefox Quantum both, on windows 10 and macOS. I do not have any complaints 
regarding other browsers (yet?). Requested HTML pages are delivered empty or 
even cut in the middle. There is no recurring pattern, it's like a lottery, 
still, very seldom.. The yet simple but not satisfiable solution is to restart 
the browser.

I know the provided information is quite spare, so my question is actually, if 
there Is there any guideline I can follow to provide you more information? I've 
appended some snippets of the proxy configuration.

Cheers,
Max

global
log 127.0.0.1 local2
chroot  /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
userhaproxy
group   haproxy
daemon
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
# make ssl safe
  ssl-default-bind-options no-sslv3 no-tls-tickets
  ssl-default-bind-ciphers 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

  ssl-default-server-options no-sslv3 no-tls-tickets
  ssl-default-server-ciphers 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
tune.ssl.default-dh-param 2048

defaults
modehttp
log global
option  httplog
option  dontlognull
option forwardfor   except 127.0.0.0/8
option  redispatch
retries 5
timeout http-request10s
timeout queue   2m
timeout connect 20s
timeout client  2m
timeout server  60m
timeout http-keep-alive 2m
timeout check   20s
maxconn 15000
balance roundrobin
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /secretpath?secretparam
stats auth secretusr:secretpasswd

frontend frontend_https-sni
bind *:443 ssl crt /etc/haproxy/ssl/ crt /etc/haproxy/LE/crt strict-sni 
alpn h2,http/1.1
mode http
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend %[ssl_fc_sni,lower,map_dom(/etc/haproxy/switch_ssl.map)]
  
backend bknd_ssl_offloading_xx
mode http
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https