HTTP Monitor generated receive string is not intended regex

[notandy]

If in octavia an expected_codes is defined as a range (e.g. 200-399), the generated regex is not correct. Currently, it looks like this:

HTTP/1.(0|1) [200-399]

But it should look like this:

HTTP\/1.(0|1) [2-3][0-9][0-9]

see

octavia-f5-provider-driver/octavia_f5/restclient/as3objects/monitor.py

Line 156 in d3ccf2b

recv_text = "HTTP/{} [{}-{}]".format(

for implementation details

[BenjaminLudwigSAP]

This value is used as the receive parameter of the monitor AS3 class. Since its default value is "HTTP/1." the forward slash probably does not have to be escaped. Both this question as well as the character class behavior (which you're most probably right about) depend on the regex engine being used for evaluating the receive parameter. @m-kratochvil can you please check which one it is?

[m-kratochvil]

Yes, this is documented in:https://my.f5.com/manage/s/article/K5917

With some exceptions, health monitors on BIG-IP systems support the use of POSIX Extended Regular Expressions (ERE). ERE syntax treats most characters as literals, meaning that they match only themselves, and defines metacharacters, which can be used to represent special characters, multiple characters, or a sequences of characters.

I also agree that the forward slash does not seem to require escape in the Big-IP monitor configuration, judging by the fact we normally use expression like HTTP/1.(0|1) 200 OK\r\n\r\n and it works. Testing in various online regex validators gets me varying results.

[notandy]

it's not about the forward slash....

[m-kratochvil]

Of course not. The regex [200-399] is wrong (even though it works most of the times), at least for the use case of matching HTTP response codes 200 - 399.
AFAIK it breaks down to 20 0-3 99 within single character class which is not what we want, not only is the logic broken but it won't match for example any middle digits in the range 4-9 (not that there are any known codes like that but that's beside the point), and it will match for example 002.

[m-kratochvil]

Another use-case where this bug surfaced: https://convergedcloud.slack.com/archives/CSP5GMKD1/p1687332168839529