HTTP Monitors Behave Differently in BigIP LTM v10/v11
I needed to create a custom http monitor for an Adobe CQ implementation. Having upgraded our environment from v9 to v10 (and then v11) only fairly recently, this was my first time having to set up a custom http monitor on our BigIPs because none of my existing monitors was suitable.
The first thing I noticed post v10 upgrade was that the Send String in the default monitors had changed to include a carriage return/line feed (CRLF) after the resource, (i.e. from GET / to GET /\r\n). A typical CQ implementation may include Apache web servers as your customer- or internet-facing systems while your internal publishing servers may continue running the java container identified as Day-Servlet-Engine/4.1.24.
If everything is working as expected, a request to resource /sample/resource/page.html against your customer-facing web servers should also work against your publishing servers. So, I set up a monitor that performed periodic GET requests for /sample/resource/page.html. The send string in the http monitor looked similar to this: GET /sample/resource/page.html\r\n
When applied to the apache pool, the monitor worked as expected but the same monitor applied to the publishing tier resulted in disabled servers. cURL requests for the exact same resource worked as expected against servers in both pools. The only thing that wouldn't work was the http monitor against the publishing servers.
As it turned out, two CRLF's needed to be sent to the cq publishing server http listener, but, luckily, changing the send string in the http monitor from GET /sample/resource/page.html\r\n to GET /sample/resource/page.html\r\n\r\n worked fine against both Apache and the Day servlet engine.
Note to Self: Some app servers need two CRLFs in the http monitor.
