Thank you Christopher and Willy for your responses !

We have discussed the resolution for the issue on GitHub at following link:
However to further explain the patch fix, we have introduced new options, 
"header" and "body" in http-check directive. Based on the content for these 
options configured in haproxy.cfg and if expect option is also configured for 
http-check, the header is added to a buffer followed by the "Connection: close" 
string which is further followed by the body.
For cases, when either header or body or both is not configured in haproxy.cfg, 
we have used default values to create the data packet in the buffer.
We would definitely update the documentation once the patch is finalized and 
therefore shared it with RFC tag.

To answer your  query on reg-test, We have performed regression testing of the 
patch using the RT suite available at our end. We can share with you the test 
report, if required. However, if there is any community RT suite that you would 
like us to follow, please do let me know.

As far as the relevance of this patch is concerned, considering the planned 
http-check refactoring at your end, we were already aware that the patch might 
not be merged due to the  fact that the check system is currently being 
reworked to support muxes for HTTP/1 and HTTP/2 so that there are better checks 
in 2.2

Kiran Gavali

-----Original Message-----
From: Willy Tarreau []
Sent: Thursday, March 26, 2020 1:07 PM
To: Christopher Faulet <>
Cc: Kiran Gavali <>;; Shivharsh 
Singh <>; Priya Ranjan 
<>; Ramanpreet Singh Bakshi 
Subject: Re: [RFC] BUG/MEDIUM: Checks: support for HTTP health checks with POST 
and data corrupted by extra connection close

Hi Christopher,

On Thu, Mar 26, 2020 at 07:40:06AM +0100, Christopher Faulet wrote:
> Thanks ! However there are many problems with your patch. First there
> is no commit message. You must explain what is exactly the problem and
> how you fix it. Then, the documentation must be updated. You
> introduced 2 new options without any explanation. Without these info,
> it is really hard to figure out what the patch do.

I noticed these as well, thanks for pointing out before me :-)

> But reading how headers and body buffers are inserted in the request,
> I suspect some bugs. A reg-test is probably necessary to validate such
> feature.

Yes that would indeed be useful.

> But, don't bother for now submitting a new patch. I'm currently
> refactoring the tcp-checks. But on my todo list, the next big step is
> the http-check refactoring. It is painful but I hope to finish the
> refactoring of the checks for the 2.2.0.

My main concern is the backward compatibility. Kiran's patch is small enough to 
be backported, so that might constitute a possible solution for existing 
setups. However we cannot afford to do that if it works differently than what 
we'll have in the final release. As such I think it's important to quickly 
figure how we want such a separate body part to be *configured* and make sure 
that it's done the same in your new version and in Kiran's patch. If so, then 
we could imagine merging it early to have it backported so that it's ultimately 
replaced in 2.2 by your work once ready.

What do you think ?

 The contents of this e-mail and any attachment(s) are confidential and 
intended for the named recipient(s) only. It shall not attach any liability on 
the originator or NECTI or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the 
opinions of NECTI or its affiliates. Any form of reproduction, dissemination, 
copying, disclosure, modification, distribution and / or publication of this 
message without the prior written consent of the author of this e-mail is 
strictly prohibited. If you have received this email in error please delete it 
and notify the sender immediately.

Reply via email to