Most network debugging starts with the question "what does the server see?" Sometimes the answer requires injecting a header that the client never sets on its own, a trace id, a feature flag, or a privacy hint. addRequestHeaderAction is the simplest way to do that from Fluxzy, scoped to any subset of traffic you can describe with a filter.
Use addRequestHeaderAction when you want every matching request to carry an extra header that the client cannot or should not add itself. Because it appends rather than replaces, it is safe to stack with whatever the client already sends.
Typical situations include:
X-Request-Id or X-Trace-Id so you can correlate them in upstream logs.X-Feature: beta to flip server side behaviour for a session.DNT: 1 or Sec-GPC: 1 for tests that depend on them.The action evaluates on requestHeaderReceivedFromClient, so the header is in place before the request reaches the upstream server.
Pair with a backend that logs X-Trace-Id to follow a request through several services without changing the client.
rules:
- filter:
typeKind: HostFilter
pattern: api.example.com
actions:
- typeKind: AddRequestHeaderAction
headerName: X-Trace-Id
headerValue: fluxzy-capture-session-42
Useful when a backend reads a header to enable a beta. Scope by source IP or process so production users are unaffected.
rules:
- filter:
typeKind: FilterCollection
operation: And
children:
- typeKind: HostFilter
pattern: app.example.com
- typeKind: ProcessNameFilter
pattern: chrome
actions:
- typeKind: AddRequestHeaderAction
headerName: X-Feature-Flag
headerValue: new-checkout
Add the header proxy wide so the browser does not have to be reconfigured.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: AddRequestHeaderAction
headerName: DNT
headerValue: "1"
Append a request header.
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
addRequestHeaderAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| headerName | string | ||
| headerValue | string |
The following examples apply this action to any exchanges
Add DNT = 1 header to any requests.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: AddRequestHeaderAction
headerName: DNT
headerValue: 1
Add a request cookie with name cookie_name and value cookie_value.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: AddRequestHeaderAction
headerName: Cookie
headerValue: cookie_name=cookie_value
View definition of AddRequestHeaderAction for .NET integration.
The following actions are related to this action:
The new header is appended, so the request carries both. For HTTP/2 and HTTP/3 this is usually fine; on HTTP/1.1 most servers merge values with a comma. Use updateRequestHeaderAction if you need to replace instead of append.
No. HTTP/2 pseudo headers are managed by Fluxzy and the protocol layer. Use changeRequestMethodAction and changeRequestPathAction for those.
List multiple AddRequestHeaderAction entries under the same actions array. They are applied in order and stack on the request.
Yes. You can reference variables defined with setVariableAction in the headerValue field, so values can be computed once and reused across rules.