"Bad request, malformed first line" in Audit Proxy log

[henrikalmen]

We have implemented an external loadbalancer for our Qlik Sense Enterprise multinode setup, and it is making simple GET requests to fetch an HTML file from the content library so that the loadbalancer knows that the server is alive.

The proxy receives the result and is satisfied, but the Audit Proxy log has warnings:

Bad request, malformed first line: GET /anonvp/content/HealthCheck/index.html↵↓

At the end of that log line there are symbols that I assume indicate CR/LF, is that what the warning is about? There are no hidden chars in the url in the loadbalancer config, but maybe the loadbalancer adds them itself.

It's a warning in the log, not an error. But there are so many of them since the loadbalancer(s) are requesting the healthcheck page quite often, and it's disturbing to have it in the log when looking for other errors.

Should I just forget about this and get on with my life, or does anyone have an idea on where to look and what to do to solve this issue?

[Benoit_C · Accepted solution]

Hi @henrikalmen,

The symbols at the end of the log line do indicate a carriage return and line feed, which are usually included in the end of HTTP requests.

It's possible that the load balancer is adding additional formatting characters to the request, which is causing the warning message in the Audit Proxy log. This may not be a critical issue.

To troubleshoot this, you may want to check the load balancer configuration and logs to see if there are any additional formatting characters being added to the requests. You could also try making the health check request manually, without using the load balancer, to see if the same warning message appears in the Audit Proxy log.

If you can confirm that the warning message is related to the load balancer, and it's not causing any other problems, then it may be okay to ignore it. However, if it's causing too much noise in the log or you're concerned about its impact, you may want to consider adjusting the load balancer configuration or implementing a different health check method.
 

Regards,
Benoit

[henrikalmen]

I think we're just going to have to give up and accept the warning messages (or, as you say, eventually use a completely different method for status checking). Everything seems right in all ends, except for in the proxy log. Doing the same fetch with cUrl or with any web browser doesn't render the warning message, and the loadbalancer seems happy with its request and the response.