"Content check monitors are designed to determine whether a service is available and whether the server is serving the appropriate content."
Also in the same article, "You can also use the default null Receive String value [""] [in a content check monitor]. In this case, any content retrieved is considered a match." (Emphasis mine.)
In other words, without a receive string, a content check monitor satisfies only its first purpose - "to determine whether a service is available." To satisfy the second purpose of a content check monitor - "to determine if the server is serving the appropriate content" - you must include a Receive String with the appropriate content. This is by design, as F5 cannot possibly know what constitutes appropriate content for your application. We provide the monitor shell; you customize it for your application delivery needs.
A content check monitor with no receive string is relatively powerless to assess application delivery health. In the case of your HTTPS monitor, for example, the system will establish a secure connection to the pool member, send the HTTP 0.9 GET request you provided in the Send String, and any response - including a 404 Not Found or other HTTP 500 error - is considered a successful response and the monitor will mark the pool member as available. As such, your monitor is not much more effective than a service check monitor and certainly not (necessarily) indicative of application delivery health.
Conventional wisdom is to use an appropriate receive string in a content check monitor.
ok so in that case the default https monitor in the F5 also not having receive string.So it's of no use right ? it is same as using tcp-443 monitor ? is that right .
"Content check monitors are designed to determine whether a service is available and whether the server is serving the appropriate content."
Also in the same article, "You can also use the default null Receive String value [""] [in a content check monitor]. In this case, any content retrieved is considered a match." (Emphasis mine.)
In other words, without a receive string, a content check monitor satisfies only its first purpose - "to determine whether a service is available." To satisfy the second purpose of a content check monitor - "to determine if the server is serving the appropriate content" - you must include a Receive String with the appropriate content. This is by design, as F5 cannot possibly know what constitutes appropriate content for your application. We provide the monitor shell; you customize it for your application delivery needs.
ok so in that case the default https monitor in the F5 also not having receive string.So it's of no use right ? it is same as using tcp-443 monitor ? is that right .
