[HAProxy 2.2.2] http-check send meth OPTIONS failure

Help!
1

The http-check send meth OPTIONS directive is not working correct. I got a L7RSP with response: TCPCHK got an empty response at step 2. However, if I use GET instead OPTIONS I will get L7OK. This problem only occurs in the latest version.

Of course if I use curl I will get correct response, so it’s not backend server side issue.

My HAProxy 2.1.8 Config:

listen tcp_async_pg_cluster
  bind 0.0.0.0:5432 
  mode tcp
  default-server check check-ssl verify none port 8008 inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
  http-check expect status 200
  maxconn 100
  option httpchk OPTIONS /async
  option tcplog
  option dontlog-normal
  retries 2
  server pg1 pg1-cluster.example.com:5432
  server pg2 pg2-cluster.example.com:5432
  server pg3 pg3-cluster.example.com:5432

and config of HAProxy 2.2.2:

listen tcp_async_pg_cluster
  bind 0.0.0.0:5432 
  mode tcp
  default-server check check-ssl verify none port 8008 inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
  maxconn 100
  option httpchk
  option tcplog
  option dontlog-normal
  retries 2
  http-check send meth OPTIONS uri /async
  http-check expect status 200
  server pg1 pg1-cluster.example.com:5432
  server pg2 pg2-cluster.example.com:5432
  server pg3 pg3-cluster.example.com:5432
2

Can you show me the complete output of the curl -vv please?

Also, what made you change to http-check send meth in the first place? The option is supported just fine, unless you don’t need additional headers.

3

Hi @lukastribus, I decided to rewrite all checks to handle warnings, like this one:

'option httpchk' : hiding headers or body at the end of the version string is deprecated. Please, consider to use 'http-check send' directive instead.

and curls:

# curl -vv -I https://pg1-cluster.example.com:8008/async -k -XGET 
* About to connect() to pg1-cluster.example.com port 8008 (#0)
*   Trying 172.16.1.1...
* Connected to pg1-cluster.example.com (172.16.1.1) port 8008 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* 	subject: CN=pg1-cluster.example.com
* 	start date: Nov 05 13:10:40 2019 GMT
* 	expire date: Nov 02 13:10:40 2029 GMT
* 	common name: pg1-cluster.example.com
* 	issuer: E=admins@example.com,CN=Example CA,OU=IT,O=Example,L=Boston,ST=Massachusetts,C=US
> GET /async HTTP/1.1
> User-Agent: curl/7.29.0
> Host: pg1-cluster.example.com:8008
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
HTTP/1.0 200 OK
< Server: BaseHTTP/0.6 Python/3.6.8
Server: BaseHTTP/0.6 Python/3.6.8
< Date: Tue, 25 Aug 2020 11:58:21 GMT
Date: Tue, 25 Aug 2020 11:58:21 GMT
< Content-Type: application/json
Content-Type: application/json

< 
* Closing connection 0


# curl -vv -I https://pg1-cluster.example.com:8008/async -k -XOPTIONS
* About to connect() to pg1-cluster.example.com port 8008 (#0)
*   Trying 172.16.1.1...
* Connected to pg1-cluster.example.com (172.16.1.1) port 8008 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* skipping SSL peer certificate verification
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* 	subject: CN=pg1-cluster.example.com
* 	start date: Nov 05 13:10:40 2019 GMT
* 	expire date: Nov 02 13:10:40 2029 GMT
* 	common name: pg1-cluster.example.com
* 	issuer: E=admins@example.com,CN=Example CA,OU=IT,O=Example,L=Boston,ST=Massachusetts,C=US
> OPTIONS /async HTTP/1.1
> User-Agent: curl/7.29.0
> Host: pg1-cluster.example.com:8008
> Accept: */*
> 
* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
HTTP/1.0 200 OK
* Closing connection 0
4

It seems like a bug
I’ve got a workaround though, using

option httpchk GET /

5

is it fixed in new release?

6

I’m not aware of any bug. If suggest you open a new thread if you have any problems.