API response status misses the reason phrase (RFC 7230)

[dnsmichi]

Issue and Steps to Reproduce

• Install NSClient++ and enable the webserver/API
• Run any query

curl -vvv -k 'https://10.0.10.20:8443/query/check_cpu' -H 'password: icinga'

Expected Behavior

Return a valid http status and string.

HTTP/1.1 200 OK

Actual Behavior

The reason phrase is missing causing clients which validate the RFC https://tools.ietf.org/html/rfc7230#section-3.1.2 to fail.

HTTP/1.1 200
Content-Length: 108
Set-cookie: token=frAQBc8Wsa1xVPfvJcrgRYwTiizs2trQ; path=/
Set-cookie: uid=admin; path=/

$ curl -vvv -k 'https://10.0.10.20:8443/query/check_cpu' -H 'password: icinga'
*   Trying 10.0.10.20...
* TCP_NODELAY set
* Connected to 10.0.10.20 (10.0.10.20) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=localhost
*  start date: Jun 20 09:18:52 2018 GMT
*  expire date: Jun 20 09:18:52 2019 GMT
*  issuer: CN=localhost
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET /query/check_cpu HTTP/1.1
> Host: 10.0.10.20:8443
> User-Agent: curl/7.54.0
> Accept: */*
> password: icinga
>
< HTTP/1.1 200
< Content-Length: 379
< Set-cookie: token=F69AzBlax3CF3EDNhm3soLBPh71Yexui; path=/
< Set-cookie: uid=admin; path=/
<
* Excess found in a non pipelined read: excess = 507, size = 379, maxdownload = 379, bytecount = 0
* Connection #0 to host 10.0.10.20 left intact
{"header":{"source_id":""},"payload":[{"command":"check_cpu","lines":[{"message":"OK: CPU load is ok.","perf":[{"alias":"total 5m","int_value":{"critical":90,"unit":"%","value":0,"warning":80}},{"alias":"total 1m","int_value":{"critical":90,"unit":"%","value":1,"warning":80}},{"alias":"total 5s","int_value":{"critical":90,"unit":"%","value":1,"warning":80}}]}],"result":"OK"}]}

Details

• NSClient++ version: 0.5.2.39 2018-02-04
• OS and Version: Windows 10
• Checking from: custom http client

Additional Details

Implementation is done with boost asio & beast on the client side, https://github.com/boostorg/beast/issues/592 shed some light here.

[mickem]

Thanks, will be fixed in the next nighty build.