The rule file

Global syntax

The "rule file" is a straightforward yaml file, shared between the three tool, containing a list of directives that fluxzy will evaluate during the proxying.

Here is a basic sample:

- filter: 
    type: HostFilter
    operation: endsWith
    - type: setRequestCookieAction
      name: my-session-cookie
      value: my-session-value
- filter: 
    type: PostFilter
    - type: AddResponseHeaderAction
      headerName: X-Proxy
      headerValue: Passed through fluxzy
    - type: ForceHTTP11Action

The root element rules must be unique within the file and contains a list of one filter and multiple actions.

In this example, there are two distinct rules:

  • The first rule, triggered when the Host the domain or the subdomain of, will add a cookie to the request.
  • The second rule, triggered when the HTTP method is POST, will add a response header and force the HTTP version to 1.1.

You have probably noted that inside a rule, there can be multiple actions for one filter. To enable multiple filtering, a special filter named FilterCollection can combine multiple filter with a merging operation (OR or AND). Children filters of this collection can also be another collection.

When the scope of two or more rules overlap, the order of evaluation will be the order of appearance in the file.

Finaly filter names and actions are case insensitive and suffix Filter and Action can be omitted.

  • You can browse any available filter and action in the search rule page. Directive page contains a sample of how to use it and how to integrate it with Fluxzy.Core library.

Using variables

You can define, reuse and extract variables during a capture session.

Inside a rule file, a variable can be called with the following syntax:


The prefix user is mandatory to access to an user defined variable. Following the same syntax, a process environment variable can be accessed with the prefix env.

  • Variable name are case insensitive
  • Variable can only be string values

Extracting a variable

Extracting variable is done by filters based on string search operation. These type of filters can be identified by the property pattern and operation.

The extraction is triggered when the operation is a regex and the regex formula contains a named capture group.

For example, the following rule will extract a bearer token from any request :

- filter: 
    type: requestHeaderFilter
    name: Authorization
    pattern: Bearer (?<TOKEN>.+)
    operation: regex
    - type: stdOutAction
      text: Found token ${user.TOKEN}

We use the syntax ${user.TOKEN} to reference the variable extracted from a previous filter.

The prefix user is mandatory to access to an user defined variable.

Predefined variables

fluxzy has some built-in variables related to the current processed exchange

Variable name Description The destination host
authority.port The destination port true if the destination require https, false otherwise Identifier of the exchange
exchange.url The absolute url of the exchange
exchange.method The request method
exchange.path The path and query of the method
exchange.status The HTTP response status
global.filterScope The current filterScope. Values can be found here

The predefined variables will return an empty string when not set (example: the response was not received or aborted).


You can use SetVariableAction to define a variable from a rule file. You can find more on its dedicated page.

- filter: 
    type: PostFilter
    - type: SetVariableAction
      # eval the action only when the response header is received
      scope: responseHeaderReceivedFromRemote 
      name: foo 
      value: bar