I have built the following monitor:
GET /lexsoft/sgbplus/#default:0 HTTP/1.1\r\nHost: test.test\r\nConnection: Close\r\n\r\n
as return code I expect a 200 OK but get a 400 back
HTTP/1.1 400 Bad RequestDate: Wed, 14 Jul 2021 05:32:30 GMT
Server: Apache/2.4.6 (Red Hat Enterprise Linux)
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>400 Bad Request</title>
<p>Your browser sent a request that this server could not understand.<br />
If I do the following CURL command I get my 200 back
curl -v http://test.test/lexsoft/sgbplus/#default:0
* Trying test.test...
* Connected to test.test (x.y) port 80 (#0)
> GET /lexsoft/sgbplus/ HTTP/1.1
> Host: test.test
> User-Agent: curl/7.47.1
> Accept: */*
< HTTP/1.1 200 OK
What should my monitor look like to get the desired result?
Thanks for your help
Additionally to suggestion, take a look at RFC3986: https://datatracker.ietf.org/doc/html/rfc3986#section-3.5
Notice the # in the URL? It is called a Fragment, typically used to identify a portion of a html document.
This is another example: https://support.f5.com/csp/article/K12783074#p2
It is linking to a headline in the solution page.
I am not exactly sure how health monitors handle the hash mark... Might be your issue.
Have times "#default:0" that deleted.
But has not led to any new result
What is interesting, with two servers that have been in the pool for a while, the check to works as described above. Only with the two new servers I always get the answer 400 back
The F5 description is about SSL.
For me it is pure HTTP traffic
I have choosen the link to the F5 solution randomly. I wanted to show you what the hash mark (#) does in a link. The is linking to a specific section in the html document you get from the server.
In your browser, when you open http://www.mysite.com/subsite1 - you will go to the top of subsite one. When you open http://www.mysite.com/subsite1#headline2 - you will jump to headline 2 of subsite1.
I am not sure how the monitors of the BIG-IP handle the #.