Hi Rahul, On Fri, Dec 08, 2017 at 12:00:51PM +0530, Rahul Ghanate wrote: > Hi, > > Here is the post I have added on discourse about the issue with httpchk > POST request, which you can find at, > https://discourse.haproxy.org/t/httpchk-post-adding-connection-close-after-data/1875 > The > content of the post is, > > =========== > > I have setup haproxy 1.7.8 with option httpchk for my backend servers and > have working GET requests. > But while configuring the POST request with json data, I am getting error > code 400. > > Here is my check added in backend block, > > option httpchk POST /myService/endpt HTTP/1.1\r\nContent-Type:\ > application/json;charset=UTF-8\r\nContent-Length:\ > 169\r\n\r\n{\"inputs\":[{\"id\":1,\"productType\":\"productType\",\"productDescription\":\"productDescription\",\"metaDescription\":\"metaDescription\",\"metaTitle\":\"metaTitle\",\"rawxyz\":\"rawxyz\"}]} > http-check expect rstatus (2|3)[0-9][0-9] > > After debugging with wireshark capture I came to know that, haproxy is > adding *\r\f"Connection: close"\r\f\r\f* at the end of the post json data. > >From this manual, https://www.haproxy.org/download/1.7/doc/configuration.txt, > I found that haproxy appends it if httpchk is combined with *http-check > expect*. > But it should be added to header fields and not after data. > > This is causing packet parse failure, as it considering POST data as a part > of header and reporting extra CRLF in headers. > > [image: image] > image.png765x161 32.2 KB > <https://discourse-cdn-sjc1.com/business/uploads/haproxy/original/1X/99bf68d48ab6538ba29d14a88307daa7b50c694f.png> > > I would need the http-check expect block to verify error code, but then how > would I avoid adding *Connection: close* at the end.
Good diagnostic. I didn't remember we had this. I'm not sure what the best solution is now. The problem with checks is that there's no notion of headers or body, it's just a data block that is sent. Maybe we could modify the code to try to modify the buffer contents in place. I'm seeing that the send-state header has the same problem a few lines above in the code by the way. I'm wondering if instead we shouldn't add a new http-check directive that would help define the body to send after the request and which would automatically compute the content-length as a bonus. We could then have something like this : option httpchk POST /myService/endpt HTTP/1.1\r\nContent-Type:\ application/json;charset=UTF-8 http-check body {\"inputs\":[{\"id\":1,\"productType\":\"productType\",\"productDescription\":\"productDescription\",\"metaDescription\":\"metaDescription\",\"metaTitle\":\"metaTitle\",\"rawxyz\":\"rawxyz\"}]} http-check expect rstatus (2|3)[0-9][0-9] And maybe layer we could imagine having "http-check header" to add some headers instead of the usual trick with \r\n above. I don't have much time to estimate the amount of work needed for this given the pending issues on HTTP/2, but I'm willing to help anyone who wants to give it a try, and even to try to backport it to 1.7 as a fix. Willy