Server set cookies drive most of the session behaviour in modern web apps, which makes them a common target during debugging. setResponseCookieAction lets you write the cookie you need straight from the proxy, complete with the security attributes that real browsers care about, without waiting for the upstream service to be updated.
setResponseCookieAction adds a Set-Cookie header to the response so the client stores a cookie with the attributes you configure. The upstream service does not need to be aware of it.
Reach for it when:
Pair it with setRequestCookieAction to drive the full session loop without restarting the client.
Smallest possible form. Fluxzy adds a Set-Cookie header with just the name and value, no domain or expiration.
rules:
- filter:
typeKind: HostFilter
pattern: app.example.com
actions:
- typeKind: SetResponseCookieAction
name: session_id
value: A1B2C3D4E5
Useful when validating that a client correctly handles HttpOnly, Secure, and SameSite=Strict, even if the upstream does not yet set them.
rules:
- filter:
typeKind: HostFilter
pattern: app.example.com
actions:
- typeKind: SetResponseCookieAction
name: auth_token
value: 0123456789abcdef
path: /
domain: app.example.com
maxAge: 3600
httpOnly: true
secure: true
sameSite: Strict
Lets QA hit a specific variant without re running an A/B assignment flow. The expireInSeconds field controls how long the cookie sticks around.
rules:
- filter:
typeKind: HostFilter
pattern: app.example.com
actions:
- typeKind: SetResponseCookieAction
name: experiment_bucket
value: variant_a
path: /
expireInSeconds: 86400
sameSite: Lax
Add a response cookie. This action is performed by adding Set-Cookie header in response.
Evaluation scope defines the timing where this filter will be applied.
responseHeaderReceivedFromRemote This scope occurs the moment fluxzy has done parsing the response header.
setResponseCookieAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| name | string | Cookie name | |
| value | string | Cookie value | |
| path | string | Cookie path | |
| domain | string | Cookie domain | |
| expireInSeconds | integer | Cookie expiration date in seconds from now | |
| maxAge | integer | Cookie max age in seconds | |
| httpOnly | boolean | HttpOnly property | false |
| secure | boolean | Secure property | false |
| sameSite | string | Set SameSite property. Usual values are Strict, Lax and None. Check |
The following examples apply this action to any exchanges
Set a cookie with name my-cookie and value my-value.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: SetResponseCookieAction
name: my-cookie
value: my-value
Add cookie with all properties.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: SetResponseCookieAction
name: my-cookie
value: my-value
path: /
domain: example.com
expireInSeconds: 3600
maxAge: 3600
httpOnly: true
secure: true
sameSite: Strict
View definition of SetResponseCookieAction for .NET integration.
The following actions are related to this action:
Fluxzy adds a Set-Cookie entry. Browsers and HTTP clients store cookies by name, so the new value wins for matching domain and path combinations.
The usual values are Strict, Lax, and None. Setting None usually requires secure to be true so modern browsers accept the cookie.
Both express a lifetime, but they map to different cookie attributes. maxAge sets the Max-Age attribute, while expireInSeconds sets an Expires date computed from the current time. You can use either or both depending on the client behaviour you need.
Yes. The action runs after the response headers are parsed, regardless of the status code.