Re: http-use-htx and IIS
Le 08/02/2019 à 15:55, Willy Tarreau a écrit : Hi Marco, On Fri, Feb 08, 2019 at 02:20:53PM +0100, Marco Corte wrote: 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 (..) 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. Could you please give a few extra indications like : - the approximate size of the POST request - the approximate size of the response (if any) - the request headers haproxy sends to IIS - the response headers haproxy receives to IIS You can run haproxy in debug mode (-d) and you'll get all these at once, it will significantly help figure where to search. Hi, Just for the record. I worked on this issue with Marco off-list. And a fix was merged and backported to 1.9. For details, see git.haproxy.org/?p=haproxy.git;a=commit;h=6cdaf2ad -- Christopher Faulet
Re: http-use-htx and IIS
Hi Marco, On Fri, Feb 08, 2019 at 02:20:53PM +0100, Marco Corte wrote: > 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 > (..) > 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. Could you please give a few extra indications like : - the approximate size of the POST request - the approximate size of the response (if any) - the request headers haproxy sends to IIS - the response headers haproxy receives to IIS You can run haproxy in debug mode (-d) and you'll get all these at once, it will significantly help figure where to search. Thanks, Willy
Re: http-use-htx and IIS
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
Re: http-use-htx and IIS
Il 2019-02-07 17:50 Marco Corte ha scritto: A configuration similar to the following lets the GETs work properly, but the POST fails after the server timeout (session state "SD" in haproxy logs): Sorry. I was wrong. It is a capital "S" S : the TCP session was unexpectedly aborted by the server, or the server explicitly refused it. Anyway it happens _many seconds_ after the request. .marcoc
http-use-htx and IIS
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. A configuration similar to the following lets the GETs work properly, but the POST fails after the server timeout (session state "SD" in haproxy logs): listen tesi-http bind 10.64.44.112:443 name HTTPS ssl crt XXX option http-use-htx server vxws142a-82 11.22.33.44:82 If the connection to the real server is closed, all GETs and POSTs work listen tesi-http bind 10.64.44.112:443 name HTTPS ssl crt XXX option http-use-htx option http-server-close server vxws142a-82 11.22.33.44:82 In other words, it seems that the "option http-use-htx" only works together with "http-server-close" with this real server. Notes: . The behaviour does not change if "alpn h2,http/1.1" is added/removed from the "bind" line. . The behaviour does not change if the browser is firefox or IE . With tcpdump on the haproxy node I was not able to understand who is waiting for whom :-) . I am not sure that I can install wireshark on the real server. Can someone please suggest me what to look for in the IIS or in the haproxy configuration? Thank you .marcoc
