Thank you Christopher and Willy for your responses ! We have discussed the resolution for the issue on GitHub at following link: https://github.com/haproxy/haproxy/issues/16 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 Thanks, Kiran Gavali -----Original Message----- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Thursday, March 26, 2020 1:07 PM To: Christopher Faulet <cfau...@haproxy.com> Cc: Kiran Gavali <kiran.gav...@india.nec.com>; haproxy@formilux.org; Shivharsh Singh <shivharsh.si...@india.nec.com>; Priya Ranjan <priya.ran...@india.nec.com>; Ramanpreet Singh Bakshi <ramanpreet.bak...@india.nec.com> 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 ? Thanks, Willy ________________________________ 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.
