cancel
Showing results for 
Search instead for 
Did you mean: 

Monitor Layer 7

Hoang_Hung
Cirrus
Cirrus

Dear all

I have a backend use web service port 8010. After I have using monitoring layer 7 but it not working.

I have tried curl-v https://abc:8010/swagger/index.html

Response: 

> GET /swagger/index.html HTTP/1.1
> Host: abc:8010
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.20.1
< Content-Type: text/html;charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: ; path=/; Httponly; Secure
<
<!-- HTML for static distribution bundle build -->
<!DOCTYPE html>
<html lang="en">

My monitor on F5: Type: http

Send string: GET /swagger/index.html

Receive string: 200  (but not working and after I tried Receive string: OK\r\n$ still not working)

Plz expain help me.

Thanks

Hoang Hung

1 ACCEPTED SOLUTION

Please try a Send-string of (and make sure to replace the hostname of abc with the hostname you were actually using in your cURL request):

GET /swagger/index.html HTTP/1.1\r\nHost: abc:8010\r\nUser-Agent: curl/7.79.1\r\nAccept: */*\r\n\r\n

... and a Receive-string of (accepting status codes of 200 or 301 or 301). This string is handled as a non case-sensitive regular expression:

^HTTP/1\.[01]\s+(200|301|302)

 It will look for a response using HTTP/1.0 or HTTP/1.1 followed by at least one whitespace character (\s+) followed by one of the acceptable status code.

If you are absolutely sure there will be a HTTP/1.1 200 OK in the response, you can put it in as well. The dot (.) in "HTTP/1.1" is handled as a wildcard (it is still treated as a regexp), but this shouldn´t matter.

Keep in mind, that some webservers don´t reply with a reason phrase (here it is the OK; might be MOVED PERMANENTLY, FOUND etc.). That´s why it is now best practice not to include it in your receive string. 

View solution in original post

5 REPLIES 5

Hello Hoang,

Try this query instead:

GET /<filename/path> HTTP/1.1\r\nHost: <hostname>

REFhttps://support.f5.com/csp/article/K2167

The receive string could be something like this

^HTTP.1\.[0|1]\s200

Also take into account this

https://cdn.f5.com/product/bugtracker/ID874877.html

 

Regards,
Dario.

As @Dario_Garrido wrote, adding the http protocol and the host header does the trick.

Without adding the protocol your server will very likely respond with a bad request (status code 400), because it assumes you are trying to use HTTP/0.9.

Please see this article for details: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP 

Even the BIG-IP automatically adds a double carriage return / line feed sequence by default, it is best practice to add it yourself in the send-string:

GET /<filename/path> HTTP/1.1\r\nHost: <hostname>\r\n\r\n

Hi @StephanManthey and @Dario_Garrido 

I have used test monitor follow https://support.f5.com/csp/article/K81239024 . After I tried GET it working

GET /<filename/path>
Recevie string: abc 

 If i used recevie code it fail.

Thanks

Hoang Hung

Please try a Send-string of (and make sure to replace the hostname of abc with the hostname you were actually using in your cURL request):

GET /swagger/index.html HTTP/1.1\r\nHost: abc:8010\r\nUser-Agent: curl/7.79.1\r\nAccept: */*\r\n\r\n

... and a Receive-string of (accepting status codes of 200 or 301 or 301). This string is handled as a non case-sensitive regular expression:

^HTTP/1\.[01]\s+(200|301|302)

 It will look for a response using HTTP/1.0 or HTTP/1.1 followed by at least one whitespace character (\s+) followed by one of the acceptable status code.

If you are absolutely sure there will be a HTTP/1.1 200 OK in the response, you can put it in as well. The dot (.) in "HTTP/1.1" is handled as a wildcard (it is still treated as a regexp), but this shouldn´t matter.

Keep in mind, that some webservers don´t reply with a reason phrase (here it is the OK; might be MOVED PERMANENTLY, FOUND etc.). That´s why it is now best practice not to include it in your receive string. 

More info about regex

https://support.f5.com/csp/article/K5917

Regards,
Dario.