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

Reply via email to