Re: Seeing server termination_state SD after updating from 1.6.11 to 1.7.5

[Bernard McCormack]

I’ve done some more testing. After changing the frontend ngnix to use ‘’’ 
proxy_http_version 1.1’’’ 
The errors stopped occurring. I wonder if it has to do with how haproxy handles 
http/1.0 request?

Our current configuration was 

Nginx (http/1.0)-> haproxy -> backend server

Working configuration 

Nginx (http/1.1)-> haproxy -> backend server



On 6/2/17, 5:01 AM, "Willy Tarreau"  wrote:

On Fri, Jun 02, 2017 at 09:46:34AM +0200, Pavlos Parissis wrote:
> In the network capture, I didn't see the HTTP response header 
Content-Length, which could confuse
> haproxy and mark the connection as terminated from server side during 
data transfer as haproxy
> didn't know the actual size of response. I am assuming here that, haproxy 
reads the value of
> Content-Length and it will mark a request with SD if the server closes 
the connection, either by
> sending a FIN/ACK or RST, before haproxy has received the amount of data 
announced in Content-Length.

It *should not* do this (and didn't do it in the past) but it could be an
explanation if we have a bug somewhere. This one should not be too hard
to reproduce though.

Willy

High Tt

[Chad Cordero]

I have an haproxy 1.5 server set up in tcp mode connecting to three backend 
postfix servers.  The trouble is some of our groupmail clients are experiencing 
sudden jumps in Tt:

Jun  2 08:01:44 localhost haproxy[976]: 139.182.111.139:58685 
[02/Jun/2017:08:01:43.123] ft_smtp bk_postfix/mailcampaign2 1/0/971 1253 -- 
6/6/6/1/0 0/0
Jun  2 08:01:44 localhost haproxy[976]: 139.182.111.139:58663 
[02/Jun/2017:08:01:43.200] ft_smtp bk_postfix/mailcampaign3 1/0/925 1253 -- 
5/5/5/2/0 0/0
Jun  2 08:02:30 localhost haproxy[976]: 139.182.111.139:58688 
[02/Jun/2017:08:01:43.997] ft_smtp bk_postfix/mailcampaign2 1/0/46106 441 -- 
8/8/8/2/0 0/0
Jun  2 08:02:30 localhost haproxy[976]: 139.182.111.139:58689 
[02/Jun/2017:08:01:44.028] ft_smtp bk_postfix/mailcampaign3 1/0/46076 441 -- 
7/7/7/2/0 0/0

Are there any suggestions for improving my HAProxy config?

global
log 127.0.0.1 local2

chroot  /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
userhaproxy
group   haproxy
daemon

stats socket /var/lib/haproxy/stats

frontend ft_smtp
bind 0.0.0.0:25
mode tcp
no option http-server-close
timeout client 1m
log global
option tcplog
default_backend bk_postfix

frontend ft_submission
bind 0.0.0.0:587
mode tcp
no option http-server-close
timeout client 1m
log global
option tcplog
default_backend bk_postfix

backend bk_postfix
mode tcp
no option http-server-close
log global
option tcplog
timeout server 1m
timeout connect 5s
server mailcampaign1 139.182.75.70:10024 send-proxy
server mailcampaign2 139.182.75.80:10024 send-proxy
server mailcampaign3 139.182.75.78:10024 send-proxy



---
Chad Cordero
Information Technology Consultant
Enterprise & Cloud Services
Information Technology Services
California State University, San Bernardino
5500 University Pkwy
San Bernardino, CA 92407-2393
Main Line: 909/537-7677
Direct Line: 909/537-7281
Fax: 909/537-7141
http://support.csusb.edu/

---
Disclaimer: This e-mail message is for the sole use of the intended 
recipient(s) and may contain confidential and privileged information protected 
from disclosure. If the reader of this message is not the intended recipient, 
or an employee or agent responsible for delivering this message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by replying to the message 
and deleting it from your computer.

Re: HAProxy 1.7.5 cookie JSESSIONID prefix not working

[Willy Tarreau]

On Fri, Jun 02, 2017 at 03:19:36PM +, Norman Branitsky wrote:
> In each case, where insert is used, indirect is specified.
> 
> Recommended?

It's better. It says "only add the cookie if it was not already present".
It can have a positive cache effect as some caches could refrain from
caching certain responses just because of the cookie. And it will save
some bandwidth.

> Actually, is the last entry (with maxidle and maxlife) optimal?

There's no "optimal" setting, it really depends on the application
and users behaviour. Please note that it's only a value stored in
the browser so that haproxy can forcefully ignore the cookie when
it sees an old one. Most of the time you really don't need to use
this.

Willy

RE: HAProxy 1.7.5 cookie JSESSIONID prefix not working

[Norman Branitsky]

Willy,



Thanks for the explanation.



I had asked about using the following parameters:

cookie HAPROXYID insert nocache



But the current documentation shows the following examples:

cookie JSESSIONID prefix

cookie SRV insert indirect nocache

cookie SRV insert postonly indirect

cookie SRV insert indirect nocache maxidle 30m maxlife 8h



In each case, where insert is used, indirect is specified.

Recommended?
Actually, is the last entry (with maxidle and maxlife) optimal?
(My old appsession parameter had a 3H lifetime.)



-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: June-02-17 10:52 AM
To: Lukas Tribus 
Cc: Norman Branitsky ; Cyril Bonté 
; haproxy@formilux.org
Subject: Re: HAProxy 1.7.5 cookie JSESSIONID prefix not working



Hi Lukas,



On Wed, May 31, 2017 at 12:59:41AM +0200, Lukas Tribus wrote:

> Hello Norman,

>

>

> Am 31.05.2017 um 00:13 schrieb Norman Branitsky:

> > Should I continue with adding "cookie /id/" to the server statement

> > in conjunction with

> > cookie JSESSIONID prefix nocache

> >

> > Or, should I follow Lukas' suggestion and insert my own HAPROXYID

> > cookie like this:

> > cookie HAPROXYID insert nocache

>

> Personally I dislike messing with application cookies on the proxy.

> It just feels wrong, unclean and frankly unnecessary.

>

> Using a dedicated cookie seems like the right thing to do, at least in

> my opinion.

>

> I don't think there are strong technical arguments for either one of

> those configurations, this is just my personal distaste for messing

> with application data.



+1.



For those who were not there 12 years ago, "cookie prefix" was created for a 
class of mobile browsers which were not able to learn more than one cookie, so 
there was no other option but to complement the existing application cookie.



It could be argued that in environments polluted by many cookies it could be 
used to avoid hitting some browsers' limits, but quite frankly given all the 
dynamic code running in browsers nowadays, it's risky to fiddle with 
application cookies in modern applications.



The rule of one cookie per layer should apply. The LB is in front of the 
application, it should use its own cookie whenever it's possible.



Willy

Re: HAProxy 1.7.5 cookie JSESSIONID prefix not working

[Willy Tarreau]

Hi Lukas,

On Wed, May 31, 2017 at 12:59:41AM +0200, Lukas Tribus wrote:
> Hello Norman,
> 
> 
> Am 31.05.2017 um 00:13 schrieb Norman Branitsky:
> >
> > You are correct.
> >
> > I was setting the jvmRoute parameter to be the server id (AWS EC2
> > InstanceID) in my regular apps served by HAPRoxy 1.5.18.
> >
> > The HAProxy 1.7.5 testing is using a different app that obviously
> > doesn't have the jvmRoute defined.
> >
> > Should I continue with adding "cookie /id/" to the server statement in
> > conjunction with
> >
> > cookie JSESSIONID prefix nocache
> >
> > Or, should I follow Lukas' suggestion and insert my own HAPROXYID
> > cookie like this:
> >
> > cookie HAPROXYID insert nocache
> >
> >  
> >
> 
> Personally I dislike messing with application cookies on the proxy.
> It just feels wrong, unclean and frankly unnecessary.
> 
> Using a dedicated cookie seems like the right thing to do, at least in
> my opinion.
> 
> I don't think there are strong technical arguments for either one of
> those configurations, this is just my personal distaste for messing with
> application data.

+1.

For those who were not there 12 years ago, "cookie prefix" was created
for a class of mobile browsers which were not able to learn more than
one cookie, so there was no other option but to complement the existing
application cookie.

It could be argued that in environments polluted by many cookies it
could be used to avoid hitting some browsers' limits, but quite frankly
given all the dynamic code running in browsers nowadays, it's risky to
fiddle with application cookies in modern applications.

The rule of one cookie per layer should apply. The LB is in front of
the application, it should use its own cookie whenever it's possible.

Willy

Re: [PATCH] MEDIUM: ssl: disable SSLv3 per default for bind

[Willy Tarreau]

On Tue, May 23, 2017 at 05:17:24PM +0200, Emmanuel Hocdet wrote:
> I think it's time to disable SSLv3 on bind line per default.
> All configurations should have no-sslv3 (or used a ssllib without sslv3).
> SSLv3 can be enable with "ssl-min-ver SSLv3.

now merged as well, thanks!
willy

Re: [PATCH] MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list

[Willy Tarreau]

Hi Manu,

On Thu, May 18, 2017 at 12:56:46PM +0200, Emmanuel Hocdet wrote:
> Same patch, split in 3 parts for better understanding.

Now merged (after dev2 though, sorry about that).

Thanks!
Willy

[ANNOUNCE] haproxy-1.8-dev2

[Willy Tarreau]

Hi,

HAProxy 1.8-dev2 was released on 2017/06/02. It added 101 new commits
after version 1.8-dev1. Given that a lot of new stuff got merged, I
prefer to issue a new release to make it easier for testers to give it
a try.

Some of the expected breakage in -dev1 was addressed (-fwrapv, dns+kqueue,
server args after "source", OCSP not working with BoringSSL). But that's
not what is the most interesting for this release.

What's interesting is that two months after -dev1 was issued, a part of
the pending stuff was already completed and merged, and we managed to
mostly focus on this stuff, resulting in more progress than when we all
walk on each other's feet, so that looks like a better long term
organisation :
  - ability to pass the listening FDs from the old to the new process
during a reload to workaround the painful (rare but existing) RST
issue under Linux when closing the listener (Olivier). Please note
for those who might have deployed the initial patch that some minor
changes were applied a few days ago, you need an option on the stats
socket to indicate that you want it to be usable to pass fds
("expose-fd listeners").

  - openssl async API (Grant Zhang, reviewed by Emeric). Interestingly
this has unveiled a limitation in the openssl async API when used
with symmetric algorithms that Emeric tried to work around with no
luck for now, but we may get more info on this later. Anyway that's
mostly interesting for asymmetric crypto so it's not really an issue.

  - master/worker model to get rid of systemd-wrapper (William)

  - server-template (Fred) : pre-provisionning of disabled servers that
can easily be enabled over CLI/DNS/whatever.

  - dns updates (Baptiste) : now the DNS resolution doesn't depend anymore
on health checks, it's totally autonomous and can even be smarter at
distributing addresses to servers using the same FQDN.

  - dealing with the openssl version configuration mess revealed by
the new APIs (Manu and Emeric) -- this will impact some server
keywords, these are now ssl-min-ver and ssl-max-ver.

  - the maximum length of the log URI can now be configured (Stéphane Cottin)

  - modsecurity SPOA module (Thierry Fournier)

  - mod_defender SPOA module (Dragan Dosen)


Already Queued :
  - ssl-min-ver/ssl-max-ver with crt-list (Emeric just gave me his ACK)


Still in progress with active work :
  - initial multi-threading support (Emeric and Christopher)

  - HTTP/2 frontend (me)

  - RAM-based "favicon" cache (William)


For later as time permits :
  - make userlists updatable from the CLI (William) -- turning them to
maps was done already but never merged, it didn't appear sustainable
so a new approach will be followed

  - a few connection management fixes/improvements that are pending
in a few of my branches (improved close handling & polling
accuracy), possibly a hack to use eBPF to destroy empty ACKs during
reload to prevent empty connections from getting killed by close().

  - improve handling of error-file by splitting headers and body -- I
don't know if someone is still working on this, but it's still
welcome and should not interfer with the other devs

I hope I didn't forget anything, the commit log is long enough, otherwise
feel free to blame me.

All in all, I'm pretty satisfied with the progress made. And even on the
work in progress I've seen some encouraging stuff.

There were reports of slow downloads which I'm going to work on next week.
In short, when we migrated to the new frontend server, we also replaced the
cache and I thought it would be as efficient but apparently I was optimistic,
so some objects get downloaded from the (slow) master and once it happens I
think some errors invalidate the objects resulting in everyone getting them
at the same time from the slow server, making the situation even worse. I'm
not worried though as there are more solutions than problems, they will just
require some changes in my publication process, which is what I tried hard
to avoid.

Please test, play and report, as usual. This is still development code,
so no prod! BTW, some scary bugs were reported on 1.7.5 and are being
worked on, they almost certainly affect 1.8-dev2 as well. So don't be
surprized if you manage to crash it (and then report it)! That's also
why there is no 1.7.6 yet.

Please find the usual URLs below :
   Site index   : http://www.haproxy.org/
   Discourse: http://discourse.haproxy.org/
   Sources  : http://www.haproxy.org/download/1.8/src/
   Git repository   : http://git.haproxy.org/git/haproxy.git/
   Git Web browsing : http://git.haproxy.org/?p=haproxy.git
   Changelog: http://www.haproxy.org/download/1.8/src/CHANGELOG
   Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/

Willy
---
Complete changelog :
Adam Spiers (1):
  DOC: stick-table is available in frontend sections

Andrew Rodland (1):
  BUG/MINOR: hash-balance-factor 

Re: High Availability for haproxy itself

[Jiafan Zhou]

Great, thanks for the input.

First time I hear something called ExaBGP.. ;-)


On 06/02/2017 11:25 AM, komu wairagu wrote:

Thanks Raphael, the article you linked to by Vincent is very good read.

On 02/06/2017, Raphaël Enrici  wrote:

Hi,

if you are in a simple case where you only need some kind of
active/passive solution without big scaling needs on a Linux system,
look for "haproxy keepalived" on your favorite search engine, you'll
find many articles explaining the way to go.

If you need HA and horizontal scaling, take a look at the article from
Vincent Bernat here:
https://vincent.bernat.im/en/blog/2013-exabgp-highavailability

HTH,
Raph


Le 2017-06-02 10:34, Jiafan Zhou a écrit :

Hi,

Haproxy ensures the HA for real servers such as httpd. However, in the
case of haproxy itself, if it fails, then it requires another instance
of haproxy to be ready. Is there any High Availability solution for
haproxy itself?

Regards,
Jiafan

Re: High Availability for haproxy itself

[komu wairagu]

Thanks Raphael, the article you linked to by Vincent is very good read.

On 02/06/2017, Raphaël Enrici  wrote:
> Hi,
>
> if you are in a simple case where you only need some kind of
> active/passive solution without big scaling needs on a Linux system,
> look for "haproxy keepalived" on your favorite search engine, you'll
> find many articles explaining the way to go.
>
> If you need HA and horizontal scaling, take a look at the article from
> Vincent Bernat here:
> https://vincent.bernat.im/en/blog/2013-exabgp-highavailability
>
> HTH,
> Raph
>
>
> Le 2017-06-02 10:34, Jiafan Zhou a écrit :
>> Hi,
>>
>> Haproxy ensures the HA for real servers such as httpd. However, in the
>> case of haproxy itself, if it fails, then it requires another instance
>> of haproxy to be ready. Is there any High Availability solution for
>> haproxy itself?
>>
>> Regards,
>> Jiafan
>
>


-- 
Thanks,

KomuW.
https://github.com/komuw

Re: [PATCH] BUILD: ssl: fix build with OPENSSL_NO_ENGINE

[Willy Tarreau]

On Mon, May 29, 2017 at 02:56:46PM +0200, Emmanuel Hocdet wrote:
> Hi,
> 
> Last patches with openssl engine break build with boringssl.
> Fix include in the mail.

Applied, thanks Manu!
Willy

Re: [PATCHES] Major DNS changes

[Willy Tarreau]

Hi Baptiste,

On Wed, May 24, 2017 at 11:34:31AM +0200, Baptiste wrote:
> Over the last few weeks, I entirely reworked the internal resolver of
> HAProxy to make it more flexible.
> The main driver for this is to add more features related to DNS use-cases
> (SRV records, scale in / scale out a backend, DNS converter, etc...) and
> also to make it more efficient internaly and more friendly with DNS servers
> ;)
(...)

I have a few comments :

1) The following construct to copy single characters :
memcpy([len], "#", 1);
len += 1;

is better done this way :

str[len++] = '#';

I'm not changing it, it's not in a performance critical path.

2) patch 8 introduces a one-byte overflow in dns_cache_key() :
+   if (len + hostname_dn_len > size)
+   return NULL;
+   memcpy([len], hostname_dn, hostname_dn_len);
+   len += hostname_dn_len;

Here len may be equal to size.

+   str[len] = '\0';

and here it's overwritten.

+   return buf;

I'm changing it this way :

+   if (len + hostname_dn_len + 1 > size) // +1 for trailing zero
+   return NULL;

3) in patch 10, there's a strange construct :

+ return_DNS_UPD_SRVIP_NOT_FOUND:
+   list_for_each_entry(record, _p->answer_list, list) {
+   /* move the first record to the end of the list, for internal 
round robin */
+   if (record) {
+   LIST_DEL(>list);
+   LIST_ADDQ(_p->answer_list, >list);
+   break;
+   }
+   }
+   return DNS_UPD_SRVIP_NOT_FOUND;

I *think* you did this only to be sure to have a first element, but
that's not appropriate. A few points to keep in mind :
  - list_for_each_entry() must not be used in cases where the element
is deleted. list_for_each_entry_safe() must be used for this. It
just happens to work in your case because you quit after the first
change, but this is very bug-prone.

  - "if (record)" will always be true since it's the item carrying the
list you stopped on.

So I'm not totally sure about the intent there. I'm leaving it as-is
for now but I'd prefer it if you could send an update for this one. If
you just want to delete the first record and put it at the end only
when it exists, you can for example do this :

if (!LIST_ISEMPTY(_p->answer_list)) {
struct list *first = dns_p->anwser_list->n;
LIST_DEL(first);
LIST_ADDQ(_p->answer_list, first);
}

4) in patch 11, dns_dump_config() is not used anymore and looks like
debugging code as it dumps pointers. Once all the changes are done,
don't forget either to kill it, or to enclose it between #ifdef if 
you prefer to keep it around.

By the way, I don't want to be nit-picking, but :

+   /* generates a query id */
+   i = 0;
+   do {
+   query_id = dns_rnd16();
+   /* we do try only 100 times to find a free query id */
+   if (i++ > 100) {
(...)

That's 101 times and not 100 :-)

Otherwise at first glance it looks good, I've merged your series.

thanks!
Willy

Re: High Availability for haproxy itself

[Raphaël Enrici]

Hi,

if you are in a simple case where you only need some kind of 
active/passive solution without big scaling needs on a Linux system, 
look for "haproxy keepalived" on your favorite search engine, you'll 
find many articles explaining the way to go.


If you need HA and horizontal scaling, take a look at the article from 
Vincent Bernat here:

https://vincent.bernat.im/en/blog/2013-exabgp-highavailability

HTH,
Raph


Le 2017-06-02 10:34, Jiafan Zhou a écrit :

Hi,

Haproxy ensures the HA for real servers such as httpd. However, in the
case of haproxy itself, if it fails, then it requires another instance
of haproxy to be ready. Is there any High Availability solution for
haproxy itself?

Regards,
Jiafan

Re: High Availability for haproxy itself

[Stephan Mueller]

From: jiafan.z...@ericsson.com
Date: Fri, 2 Jun 2017 09:34:56 +0100
Subject: High Availability for haproxy itself
> Hi,
> 
> Haproxy ensures the HA for real servers such as httpd. However, in
> the case of haproxy itself, if it fails, then it requires another
> instance of haproxy to be ready. Is there any High Availability
> solution for haproxy itself?
> 
> Regards,
> Jiafan
> 

Hi,

its quite common to set up haproxy together with keepalived. The latter
provides you a virtual router, on which you can run a haproxy on each
node. If a node fails, keepalived switches over to another working
haproxy. There are plenty of resources how to set this up.

 hth, Stephan

Re: truncated request in log lines

[Willy Tarreau]

On Thu, May 18, 2017 at 08:58:41AM +0200, Stéphane Cottin wrote:
> commit 7fb383cbfb42e58dc7764425bc5b1c3c11a111dc
> Author: Stephane Cottin 
> Date:   Thu May 18 08:41:06 2017 +0200
> 
> MINOR: Add logurilen tunable.
(...)

Now merged, thank you Stéphane.

Willy

Re: Download site horrendously slow

[Willy Tarreau]

On Thu, Jun 01, 2017 at 10:31:00AM +0200, Pavlos Parissis wrote:
> On 05/31/2017 06:28 PM, William Lallemand wrote:
> > On Wed, May 31, 2017 at 04:15:18PM +, Skarbek, John wrote:
> >> Hey guys,
> >>
> >> Just an FYI, I'm not sure how you host the downloads for haproxy, but for 
> >> the past couple of days, they've been horridly slow.
> >>
> > 
> > You are right, I'd just test it and the download of the tarball fluctuate
> > between 1 and 2 kB/s.
> > 
> > 
> 
> I experience the same poor performance.

I've seen some performance issues as well. I'll have more time next
week to investigate and to work on a better solution.

Willy

Re: Seeing server termination_state SD after updating from 1.6.11 to 1.7.5

[Willy Tarreau]

On Fri, Jun 02, 2017 at 09:46:34AM +0200, Pavlos Parissis wrote:
> In the network capture, I didn't see the HTTP response header Content-Length, 
> which could confuse
> haproxy and mark the connection as terminated from server side during data 
> transfer as haproxy
> didn't know the actual size of response. I am assuming here that, haproxy 
> reads the value of
> Content-Length and it will mark a request with SD if the server closes the 
> connection, either by
> sending a FIN/ACK or RST, before haproxy has received the amount of data 
> announced in Content-Length.

It *should not* do this (and didn't do it in the past) but it could be an
explanation if we have a bug somewhere. This one should not be too hard
to reproduce though.

Willy

Re: Replace the systemd-wrapper by the master worker mode

[Willy Tarreau]

On Thu, Jun 01, 2017 at 05:38:49PM +0200, William Lallemand wrote:
> Those minor problems have been corrected in this new patchset.
> Please merge them if that's ok for you.

New series now merged, thanks William!

Willy

High Availability for haproxy itself

[Jiafan Zhou]

Hi,

Haproxy ensures the HA for real servers such as httpd. However, in the 
case of haproxy itself, if it fails, then it requires another instance 
of haproxy to be ready. Is there any High Availability solution for 
haproxy itself?


Regards,
Jiafan

Re: Seeing server termination_state SD after updating from 1.6.11 to 1.7.5

[Pavlos Parissis]

On 06/01/2017 04:53 PM, Bernard McCormack wrote:
>  
> 
> After updating haproxy from 1.6.11 we saw a number of errors with the 
> termination state “SD “  that
> is flooding our logs with errors. It seems to only occur on a random subset 
> of requests.  Attached
> is a pcap of failed request. I was wondering the if anyone else was seeing 
> this?  I’ve tried turning
> off gzip on the backend server but it seems to make no difference.
> 
>  
> 
> The request all appear to be functioning correctly but it is generating a 
> large number of log
> messages. The flow is browser -> nginx -> haproxy -> nginx.
> 
>  
> 
> Jun 01 09:11:01 haproxy haproxy[10519]: haproxy  haproxy[10519]: 
> 127.0.0.1:24849
> [01/Jun/2017:09:11:01.190] MAINSITE_HTTP_MASTER phpmaster_80/webphpmaster01 
> 0/0/0/790/790 200 19
> 
> 22 - - SD-- 3/1/1/0/0 0/0 {CuQGKFkwEmU5eRCEAwZoAg==} "GET /favicon.ico 
> HTTP/1.0"
> 


In the network capture, I didn't see the HTTP response header Content-Length, 
which could confuse
haproxy and mark the connection as terminated from server side during data 
transfer as haproxy
didn't know the actual size of response. I am assuming here that, haproxy reads 
the value of
Content-Length and it will mark a request with SD if the server closes the 
connection, either by
sending a FIN/ACK or RST, before haproxy has received the amount of data 
announced in Content-Length.

My assumption could be wrong, so let's wait for some more experience people to 
answer your question.

Last but not least, when you supply a network capture it is very useful to 
mention the system behind
the IPs, in your case you have nginx-haproxy-nginx and I assumed that 1st HTTP 
response (frame 16)
was from nginx to haproxy. The size of reassembled TCP payload also matches the 
response size
mentioned in the log.

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature