Hello Willy,
As per my findings, the existing "httpchk" directive contains header and body as single argument args[4] and there is no definite identifier to differentiate header from body. Therefore, i have added 2 new options to http-check directive for header and body. Specifying these options would be mandatory if "http-check expect" option is configured in haproxy.cfg file. If "http-check expect" is configured but "http-check header" and/or "http-check body" not configured, it would result into an error logged in haproxy.log Following is the pseudocode in src/checks.c file. if check->type == PR_O2_HTTP_CHK /* prevent HTTP keep-alive when "http-check expect" is used */ if s->proxy->options2 & PR_O2_EXP_TYPE if "http-check header" and "http-check body" present in the haproxy.cfg file b_putblk(&check->bo, s->proxy->header_check_req, s->proxy->header_check_len); b_putist(&check->bo, ist("Connection: close\r\n")); b_putblk(&check->bo, s->proxy->body_check_req, s->proxy->body_check_len); } else Error logged in haproxy.log ErrorMsg=Specify the header and body endif else b_putblk(&check->bo, s->proxy->check_req, s->proxy->check_len) endif endif Thanks And Regards Kiran Gavali -----Original Message----- From: Willy Tarreau [mailto:w...@1wt.eu] Sent: Monday, February 24, 2020 1:26 PM To: Kiran Gavali <kiran.gav...@india.nec.com> Subject: Re: HAProxy v2.1.0 health checks with POST and data corrupted by extra "connection: close" Hello Kiran, On Mon, Feb 24, 2020 at 07:00:08AM +0000, Kiran Gavali wrote: > Hello Mr. Willy Tarreau , > > Issue Link: https://github.com/haproxy/haproxy/issues/16 Oh I didn't notice that you've updated the report there a month ago, sorry about that, I get so many github notifications that I do miss quite some of them :-( > I have reproduced and analyzed the above bug on HAProxy v2.1.0 (using > Wireshark). > As per my findings, the "Connection: close" string is appended after > the data block instead of being appended after the header. [Refer the > attached Wireshark screenshot at the end] Yes absolutely, that's the problem (and limitation) described there. > As stated by @wtarreau<https://github.com/wtarreau> in [ > #https://www.mail-archive.com/haproxy@formilux.org/msg28200.html], it > would be best to add another option "body" to http-check directive so > as to correctly differentiate body from header, as shown below:- > > option httpchk POST / HTTP/1.1\r\n > http-check header Host: 10.10.26.236\r\nContent-Type: > application/json\r\nContent-Length: 38\r\n http-check body > {"command":"getNodeInfo"} http-check expect rstatus (2|3)[0-9][0-9] > > To incorporate the change, we need to do changes in below code:- > File: cfgparse-listen.c > Function: int cfg_parse_listen(const char *file, int linenum, char > **args, int kwm) Code Snippet: curproxy->check_len = > snprintf(curproxy->check_req, reqlen, "%s %s %s\r\n", args[2], > args[3], *args[4]?args[4]:"HTTP/1.0"); > > Please let me know if my understanding of the above issue is correct, > so that I can proceed further accordingly. Looking forward for your guidance. Your analysis is correct. However this issue is more than two years old now and the check system is currently being reworked in order to support muxes for HTTP/1 and HTTP/2 so that we have better checks in 2.2. However I don't know if for this specific issue we can come up with something trivial enough to be backported to older releases with no risk at all. I guess that it might be worth trying, but let me be clear about the fact that if the code becomes tricky, we may finally decide not to merge it and/or not to backport it. Do not hesitate to share your findings on the mailing list so that others can follow the progress and possibly suggest adjustments. 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.