Rule variables are the simplest way to share state inside a Fluxzy exchange. They let you compute a value once and let every downstream header rewrite, log line, or file write consume it without copy pasting strings.
Use setVariableAction when several rules need to share a value, when you want to compute something once and reference it later, or when you need to seed a placeholder that other actions interpolate at runtime. The value is stored in the exchange context and is available to any action that supports {{variable}} style substitution, such as stdOutAction, fileAppendAction, updateRequestHeaderAction and addResponseHeaderAction.
Pick the scope property carefully. It controls at which moment the variable is evaluated. requestHeaderReceivedFromClient is the default and matches most use cases. Use onAuthorityReceived if the value must be available before TLS negotiation, or responseHeaderReceivedFromRemote if you need to capture something from the response.
Variables set this way live for the duration of one exchange. They are not shared between requests unless you persist them externally.
Seed an environment variable on every request, then reference it from a custom header and a log line.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: SetVariableAction
name: environment
value: staging
- typeKind: AddRequestHeaderAction
headerName: X-Environment
headerValue: "{{environment}}"
- typeKind: StdOutAction
text: "request to environment={{environment}}"
Set the variable on the responseHeaderReceivedFromRemote scope so it can read response side context and feed a log file.
rules:
- filter:
typeKind: HostFilter
pattern: api.example.com
actions:
- typeKind: SetVariableAction
name: traceTag
value: api-call
scope: responseHeaderReceivedFromRemote
- typeKind: FileAppendAction
filename: /var/log/fluxzy/trace.log
text: "tag={{traceTag}}"
Most traffic uses the default tag, but a specific host gets a different label that downstream rules read.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: SetVariableAction
name: tenant
value: default
- filter:
typeKind: HostFilter
pattern: acme.api.example.com
actions:
- typeKind: SetVariableAction
name: tenant
value: acme
Set a variable or update an existing
Evaluation scope defines the timing where this filter will be applied.
requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client
setVariableAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| name | string | Variable name | |
| value | string | Variable value | |
| scope | onAuthorityReceived | requestHeaderReceivedFromClient | dnsSolveDone | requestBodyReceivedFromClient | responseHeaderReceivedFromRemote | responseBodyReceivedFromRemote | copySibling | outOfScope | The scope where the variable is evaluated | requestHeaderReceivedFromClient |
This filter has no specific usage example
View definition of SetVariableAction for .NET integration.
This action has no related action
Any action that supports {{name}} substitution can read it. Common consumers include addRequestHeaderAction, updateRequestHeaderAction, addResponseHeaderAction, stdOutAction, stdErrAction and fileAppendAction.
No. Each exchange has its own variable scope. If you need persistence between requests, write the value to a file with fileAppendAction or to an external store.
The later assignment wins, provided both actions run on the same or an earlier scope. Order rules and scopes carefully if you depend on a specific value.
Yes. Substitution is recursive at the moment the consuming action runs, so value: '{{tenant}}-prod' is resolved when a downstream action reads the variable.