Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
What is the difference between a Condition and an Action?
Short answer
Condition answers the question "which traffic?"; it looks at the request or the response, produces a true or false result and does not affect traffic on its own. Action answers the question "what is to be done?"; it adds a header, redirects, blocks or shows content. An action runs only once it is added to the Actions field of the vService; if it is bound to a condition, it runs only when the condition is met, and if it is saved without a condition, it runs on all traffic (except Location Redirection and User Authentication (On HTTP request): these two never run without a condition).
How Does It Work?
The Conditions & Actions pair is the TR7 counterpart of the rule-based traffic policies in load balancers (similar to F5 Local Traffic Policy / iRules, Citrix Responder / Rewrite policy); the rule is set up from the interface without writing code.
- A condition is defined once under Load Balancer → Conditions.
- An action is created under Load Balancer → Actions and the condition is selected in the Conditions field; multiple conditions can be combined with AND / OR, and the NOT form of each condition can also be selected.
- The action is added to the Actions field in the Details panel of the vService form.
- When a request (or response) arrives, if the condition is met, the action runs; if it is not met, the action is skipped and the next action is evaluated.
Comparison
| Condition | Action | |
|---|---|---|
| Its question | Which traffic? | What is to be done? |
| Its result | True / false | A change in the traffic |
| Effect on its own | None | Takes effect once added to the Actions field of the vService |
| Where it is defined | Load Balancer → Conditions | Load Balancer → Actions |
| Where it is used | Action, vService and profile fields (below) | Actions field of the vService |
| Example | Path starts with /admin | Block the request (Block) |
Other Places Where Conditions Are Used
Conditions are not used only in actions; all the fields below select from the same records under Load Balancer → Conditions. Which vServices and actions a condition is used in is seen in the Used in tab of the preview that opens when the row is clicked in the Conditions list (Preview of the Selected Condition).
| Where | Field | What it does |
|---|---|---|
| vService form (HTTP, L7 TCP) | Conditional Backend Services | Determines which Backend Services handle the request (Content Switching). Only request-stage conditions can be selected; there are at most 3 groups per block. |
| vService form → Details (HTTP) | Debug | Limits the Debug mode records to the requests that match the condition; if it is left empty, all requests are recorded. |
| WAF management (HTTP) | Whitelist Condition | Keeps the requests that match the condition out of WAF inspection. |
| WAF management (HTTP) | Conditional Blocking Pages | Shows a different block page to the blocked request depending on the condition. |
| WAF management (HTTP) | WAF Log Suppression Condition | Does not keep the WAF record of the requests that match the condition. |
| Bot/DDoS management | DDoS Whitelist Condition, Bot Protection Whitelist Condition, IP Reputation Whitelist Condition | Keeps the requests that match the condition out of the relevant protection. |
| Bot/DDoS management → Waiting room | Waiting room condition, Conditional Waiting Pages | Determines which requests the waiting room is applied to and which waiting page is shown to which request. |
| Cache profile | Caching Rules | Determines which responses are cached. |
| Report profile | Custom Report Fields → Table condition | Determines which requests the custom report table is built from. |
| AGS | AGS Activation Condition, the Decision Point in the flow, and the Policy Condition and Whitelist Conditions in the protection policies | Determines which requests the AGS access control and its policies are applied to. |
Actions That Do Not Take a Condition
The forms of the action types below have no Conditions field; when they are added to a vService, they are applied to all the traffic of that vService. In the Conditions column of the Actions list, - appears for these types.
- Keep Header Names
- Manage HTTP Security Headers
- HTTP Cookie Security
- Cookie Encryption
- IPFIX Log Sending
- HTTP TCP Multiplexing
- HTTP 1.0 Header Compatibility
- CORS
- Ip Log Masking
- Manual Action
- Cookie Based Connection Persistency
- Redirect for Traffic Manager Errors
- Redirect for Backend Service Errors
- Show Content for Traffic Manager Errors
- Show Content for Backend Service Errors
In all the other action types that take a condition, the Conditions field can be left empty; in this case, the action is applied to all traffic. There are two exceptions: Location Redirection and User Authentication (On HTTP request) never run if they are saved without a condition (Why doesn't a Location Redirection or User Authentication (On HTTP request) action work if I add it without a condition?).
In TR7
- Conditions are central: a condition is defined once and used in more than one action and vService; a change made to a condition is reflected everywhere it is used.
- Each condition appears in the selection lists as two options, itself and its NOT form; a NOT condition is not defined separately (Automatic NOT condition).
- The selection lists are filtered by the protocol of the action (HTTP / TCP) and its execution point (request / response); for example, Status Code can be selected only in response-stage actions.
- The selection lists also contain built-in conditions that come with the product (e.g. If the client is mobile); these do not appear in the Conditions list and are not edited.
Common Misconceptions
- "Creating a condition affects traffic." A condition does nothing unless it is used by an action or by one of the fields above.
- "Creating the action is enough." An action does not run unless it is added to the Actions field of the vService.
- "An action without a condition always runs on all traffic." Location redirection and User Authentication (On HTTP request) never run without a condition.
- "Every condition can be selected in every action." The options are filtered by the protocol and execution point of the action; in the action types that do not take a condition, the Conditions field does not appear at all.
How it is done in the documentation
