Forum Discussion
Receive String Not Reconized By Custom HTTP Health Check Monitor
Hi, We're using a custom HTTP monitor for our application that hits a specific URL and checks the response to make sure that it is correct. The F5 is not recognizing the Receive string and thus is marking the node as down.
Here is the send string: GET /syshc/health HTTP/1.1\r\nUser-Agent:BigIP Prober\r\nHost: \r\nConnection: close\r\n\r\n
Here is the receive string: SystemMonitortrue
The URL above either returns SystemMonitortrue if the application is working or SystemMonitorfalse if is not.
I have tried HTTP version 1.0 and I have set the host as either a existing host, or as a dummy host, but no luck.
The monitor log file states "Response did not match recv regex yet"
From the F5, I have done these tests in an attempt to figure out what is wrong, and I get different responses based on whether I use curl or telnet or netcat:
F5-LTM>echo -e "GET /syshc/health HTTP/1.1\r\nUser-Agent:BigIP Prober\r\nHost: \r\nConnection: close\r\n\r\n" | nc 8080
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-OneAgent-JS-Injection: true Set-Cookie: dtCookie=2$215E59177B4BD85717C0665144C1D564; Path=/ Content-Type: text/plain;charset=UTF-8 Content-Length: 40 Date: Mon, 10 Dec 2018 17:51:59 GMT Connection: close
SystemMonitorprotocol = http host = null (NOTE no true or false)
If I telnet I get this:
F5-LTM>telnet 8080 Trying ... Connected to . Escape character is '^]'. GET /syshc/health HTTP/1.1 User-Agent:BigIP Prober HOST: Connection: Close
HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-OneAgent-JS-Injection: true Set-Cookie: dtCookie=2$D90B430DD2CA1434D3DD98267CAF0952; Path=/ Content-Type: text/plain;charset=UTF-8 Content-Length: 40 Date: Mon, 10 Dec 2018 18:52:43 GMT Connection: close
SystemMonitorprotocol = http host = null (no "true" or "false")
However, if I use curl, I get the correct result:
F5-LTM>curl :8080/syshc/health SystemMonitortrue <-- correct response!
In several browsers, Chrome, Firefox, Safari and IE, the response is "SystemMonitortrue" which is the correct response.
I have scoured the following articles: https://support.f5.com/csp/article/K2167 https://support.f5.com/csp/article/K13397 https://support.f5.com/csp/article/K5917 https://support.f5.com/csp/article/K3224
What am I missing here?
- JGCumulonimbus
Try using HTTP version 1.0 without sending the "Host:" header at all.
- gscholz_370150Nimbostratus
Have you tried running a tcpdump on port 80 to see exactly how the curl request is formed to get the intended result? Then you could edit the send string accordingly.
- Ken_04_163875Nimbostratus
I have run a tcpdump on this request, and it returns the expected string (picture of Ken pulling out his hair).
What I don't understand is a telnet to this URL, with either a 1.0 or 1.1 HTTP request, fails, but a curl, using a 1.0 or 1.1 HTTP request, returns the correct string. Since the URL for the monitor check is hitting a separate war file, that then hits the application to determine it's availability, is it possible that this is considered a redirect (301) and thus telnet and the health monitor fails? There is no evidence of a redirect, either in telnet, curl, the monitor logs, or in a browser hitting the same URL...
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com