Support keyword found/not found for HTTP probe

[DannyBen]

When using http probing, it is common to check for the existence or absence of a keyword. I would love to have such a feature in easeprobe.

Implementation suggestion:

http:
- name: ...
  url: ...
  success_keyword: "Welcome to my site"
  failure_keyword: "Unauthorized"

[haoel]

I'd to define the correct behavior here. @DannyBen please help to review.

We need to check the HTTP Status Code and the response keyword. the flowing table show all senarios.

HTTP Status Code	Success Keyword Matched	Failure Keyword Matched	Result
success 👍	match 👍	no match 👎	✅
success 👍	match 👍	match 👍	❌
success 👍	no match 👎	match 👍	❌
success 👍	no match 👎	no match 👎	❌
failed 👎	match or not	match or not	❌

[DannyBen]

Yup. Sounds about right.

[haoel]

Sorry, I updated the case study table. if the success keywords are not matched, we should consider it failed.

So, there is only one scenario that is considered a SUCCESS ✅

HTTP Status Code is Good AND success keyword is matched AND failure keyword is not matched

Meanwhile, for the first version, only checks the whole string instead of each word in the success keyword string.

[DannyBen]

Ok. Actually the table confused me a little, it is easy to make mistakes when reviewing it. I see it as:

# pseudocode
status = "success"
status = "failed" if expected_http_codes configured and response_http_code is not in expected_http_codes
status = "failed" if success_keywords configured and success_keywords is not in response_body
status = "failed" if failure_keywords configured and failure_keywords is in response_body
return status

[DannyBen]

for the first version, only checks the whole string instead of each word in the success keyword string.

In my view - if the success_keywords option accepts an array, each item in the array should be checked separately. if ANY appears, its a success. Same goes for failure_keywords.

If it is easier to avoid the array, I think it is fine to just have a single string. Most monitors I know are providing just that.

[haoel]

The cases you mentioned are no problem.

But we need to understand this feature introduces complications - because there are 3 factors, and they might conflict.

For examples:

• If both success_keywords and failure_keywords are in the response body, success_keywords says success, but failure_keywords says failed. I think this should be failed

• both success_keywords and failure_keywords are not in the response body, we consider this failed as well.

That's why I give a table to do all cases study.

[DannyBen]

I understand, and my pseudocode shows that we assume success first, and ANY condition not met means failure. In my code, when I saw success_keywords present I mean "provided in the config by the user. It doesn't matter if success keywords are found in the response body, if it also contains a failure keyword, and it doesn't matter if a failure keyword is not present in the response body if success keywords were not there.

I updated the pseudocode, but if I understand correctly, we say the same thing. Any condition - if configured by the user - means failure if it is not met.

In other words, I see the table like this (assuming all three are configured by the user)

HTTP Status Code	Success Keyword Matched	Failure Keyword Matched	Result
success 👍	match 👍	no match 👎	✅
doesnt matter	doesnt matter	match 👍	❌
doesnt matter	no match 👎	doesnt matter	❌
failed 👎	doesnt matter	doesnt matter	❌

[proditis]

I think that the pseudo code described by @DannyBen covers your cases as well @haoel

If both success_keywords and failure_keywords are in the response body

Based on the pseudocode this case is indeed returning failure as you say, the fail will be raised by the 3rd check

status = "failed" if failure_keywords configured and failure_keywords is_in response_body

both success_keywords and failure_keywords are not in the response body, we consider this failed as well.

This will raise a failure by the 2nd check

status = "failed" if success_keywords configured and success_keywords is_not_in response_body

I think the logic described by the pseudocode is sound.

PS: I also got confused by the table 😄

[haoel]

Yes. We have a different way but the same destination. (Personally, I like to figure out all permutations to make sure no case is missed)

BTW, The current code implementation is exactly the same as the pseudocode logic with three checks. ;-)

[haoel]

close this issue as PR #80 merged. feel free to reopen it if have further questions.