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
