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
