Process flow

In the filtering process, the implemented rules are processed one after another, according to the positions they take in their rule sets.

The rule sets themselves are processed in the order of the rule set system, which is shown on the Rule Sets tab of the user interface.

In each of the three cycles, the implemented rule sets are looked up one after another to see which must be processed in this cycle.

When a rule is processed and found to apply, it triggers an action. The action executes a filtering measure, such as blocking a request to access a web object or removing a requested object.

In addition to this, an action has an impact on the filtering process. It can specify that the filtering process must stop completely, or skip some rules and then continue, or simply continue with the next rule.

Processing also stops after all implemented rules have been processed.

Accordingly, the process flow can be as follows:

All rules have been processed for each of the configured cycles and no rule has been found to apply. –> Processing stops.
In the request cycle, the request is allowed to pass through to the appropriate web server.
In the response cycle, the response sent from the web is forwarded to the appropriate user.
In the embedded objects cycle, the embedded object is allowed to pass through with the request or response it was sent with.
Processing begins again when the next request is received.
A rule applies and requires that processing must stop completely. –> Processing stops.
An example of a rule that stops processing completely is a rule with a blocking action.
If, for example, a request is blocked because the requested URL is on a blocking list, it is no use to process anything else.
No response is going to be received because the request was blocked and not passed on to the appropriate web server. Filtering an embedded object that might have been sent with the request is also not needed because the request is blocked anyway.
A message is sent to the user who is affected by the action, for example, to inform this user that the request was blocked and why.
Processing begins again when the next request is received.
A rule applies and requires that processing must stop for the current rule set. –> Processing stops for this rule set.
The rules that follow the stopping rule in the rule set are skipped.
An example of a rule that stops the processing of a rule set is a whitelisting rule followed by a blocking rule in the same rule set.
When a requested web object is found on a whitelist, the request is allowed to pass through without further filtering. Therefore the rule set is not processed any further and the rule that eventually blocks the object is skipped.
Processing continues with the next rule set.
The next rule set can contain rules that, for example, block a request, although it was allowed to pass through the preceding rule set.
A rule applies and requires that processing must stop for the current cycle. –> Processing stops for this cycle.
The rules and rule sets that follow the stopping rule in the cycle are skipped.
An example of a rule that stops the processing of a cycle is a global whitelisting rule.
When a requested object is found on a global whitelist, the request is allowed to pass through to the appropriate web server. To ensure the request is not blocked eventually by any of the following rules and rule sets, the request cycle is not processed any further.
Processing continues with the next cycle.
A rule applies and requires that processing continues with the next rule. –> Processing continues with the next rule.
This can be the next rule in the current rule set or the first rule in the next rule set or cycle.
An example of a rule that lets the filtering process continue unimpeded is a statistics rule.
This rule just counts requests by increasing a counter and does otherwise nothing.