Bad request on health check due to content-length header

Help!
1

hello everyone,

I attempted to upgrade from 2.2 to 2.4 but some health checks return http status 400 “bad request”.
I know that it is totally valid to send content-length: 0 for GET requests according to the RFC’s but there
are many applications that do not consider those valid and return the 400 status.

So my question is whether it is possible to prevent haproxy from appending the content-length header
to http checks or not.

I have tried the following
option httpchk on it’s own
option httpchk GET /status HTTP/1.0
http-check send meth GET uri /status var HTTP/1.1 hdr Host xxx.xxx.xxx hdr User-Agent "Haproxy Health Check"
http-check send meth GET uri /status ver HTTP/1.0
and all of them add the content-length: 0 header

thank you for your time

2

Hello,
The 400 error is returned by your app. If you think this is because of the content length you can try to add a dummy body ( Link to the doc ):

body <string> add the body defined by to the request sent during
HTTP health checks. If defined, the “Content-Length” header
is thus automatically added to the request.

3

thank you for your response rhada,

my problem is with the presence of the content-length: 0 on the health check request from haproxy towards some quirky backends that consider this request as “bad” . I wanted to find a way to override haproxy’s behaviour and not send this specific header at all so that health checks return 200 OK. Using POST is not an option either because we can not alter those specific backends/applications.

4

Construct your own HTTP request and parse the response manually with tcpcheck:

option tcp-check
tcp-check comment send\ HTTP\ request
tcp-check send GET\ /status\ HTTP/1.0\r\n
tcp-check send User-Agent:\ Haproxy\ Health\ Check\r\n
tcp-check send \r\n
tcp-check expect rstring HTTP/1\..\ 200 comment check\ HTTP\ response
1 Like
5

wow, that is a very elegant solution, i feel ashamed for not coming up with it myself :slight_smile:
I added a Connection: close header just in case.

thank you lukastribus

6

HTTP/1.0 already implies Connection: close. You only need that in HTTP/1.1.

7

You are right, thank you again @lukastribus

8

I’ve had the same issue when moving from 1.8 to 2.2 and the solution works.

But I find this really weird to have to forge the check ourselves, for this common use-case.

9

Considering that the documentation implies the opposite behavior (Content-Length only added if body is defined):

body add the body defined by to the request sent during
HTTP health checks. If defined, the “Content-Length” header
is thus automatically added to the request.

This could be defined a bug (either code or documentation bug).

I agree the behavior is suboptimal, although it is RFC compliant afaik.

I suggest filing a bug at github for further discussion with the developers: