Il 2019-02-07 17:50 Marco Corte ha scritto:
Hello!
I am testing haproxy version 1.9.4 on Ubuntu 18.04.
With the "option http-use-htx", haproxy shows a strange behaviour when
the real server is IIS and if the users' browsers try to do a POST.
I activated two frontend/backend pair on the same haproxy instance,
forwarding to the same real server 10.64.44.74:82.
bind 10.64.44.112:443 -> no option http-use-htx -> server 10.64.44.74:82
bind 10.64.44.112:444 -> option http-use-htx -> server 10.64.44.74:82
I captured the communication from 10.64.44.112 to the real server
10.64.44.74:82: the traffic generated by haproxy in the two cases is
different.
This is (part of) the capture of a working POST (length 561+527)
12:53:21.973969 IP 10.64.44.112.34706 > 10.64.44.74.82: Flags [P.], seq
1:562, ack 1, win 229, options [nop,nop,TS val 2416540384 ecr
3320899791], length 561
12:53:21.974484 IP 10.64.44.112.34706 > 10.64.44.74.82: Flags [P.], seq
562:1089, ack 1, win 229, options [nop,nop,TS val 2416540385 ecr
3320899791], length 527
12:53:21.974602 IP 10.64.44.74.82 > 10.64.44.112.34706: Flags [.], ack
1089, win 2081, options [nop,nop,TS val 3320899793 ecr 2416540384],
length 0
.... and the communication continues ...
When "option http-use-htx" is active, haproxy opens the connection to
the real server, sends the headers and nothing more (length 444+133).
12:51:19.833831 IP 10.64.44.112.34678 > 10.64.44.74.82: Flags [P.], seq
148880094:148880538, ack 1910718319, win 1167, options [nop,nop,TS val
2416418245 ecr 3320745060], length 444
12:51:19.834437 IP 10.64.44.112.34678 > 10.64.44.74.82: Flags [P.], seq
444:577, ack 1, win 1167, options [nop,nop,TS val 2416418245 ecr
3320745060], length 133
12:51:19.834583 IP 10.64.44.74.82 > 10.64.44.112.34678: Flags [.], ack
577, win 2081, options [nop,nop,TS val 3320777652 ecr 2416418245],
length 0
... and the communication hangs here.
Two minutes after the POST, the real server logs a "400" error (because
a timeout is reached, I guess).
The fact that the real server is waiting for some data also matches with
the haproxy logs that have a "SD" state at disconnection.
It is difficult to anonymize the packet content and I do not want to
generate a WOT here posting the whole packet capture in clear.
If someone is interested, I can do a tcpdump and sent it to him/her.
Thank you again
.marcoc
