hasAnyCookieOnRequestFilter Filter

Q: Can I invert it to find anonymous traffic?

Yes. Set `inverted: true` and the filter will match requests that do not carry a Cookie header.

Match any outgoing request that carries at least one cookie, so you can scope rules to authenticated or stateful traffic.

Cookies are the simplest way to tell stateful traffic apart from public traffic, and most debugging workflows need to look at one or the other in isolation. The hasAnyCookieOnRequestFilter is a lightweight switch that surfaces every cookie bearing exchange, ready to be combined with tagging, throttling, or header rewriting actions.

When to use this filter

Use hasAnyCookieOnRequestFilter whenever a rule should only run on requests that already carry a Cookie header. The filter is evaluated when the request headers arrive from the client, so it is cheap and composes well with header or body actions.

Common scenarios:

Separating anonymous traffic from sessioned traffic to apply different latency or throttling rules.
Tagging cookie bearing exchanges for easy filtering in the Fluxzy session viewer.
Stripping or rewriting cookies, but only on the subset of traffic that actually has them.

Real world examples

Tag stateful exchanges for triage

Add a tag to every request that arrives with a cookie. Helps when reviewing a long capture to see which calls were authenticated.

rules:
- filter:
    typeKind: HasAnyCookieOnRequestFilter
  actions:
  - typeKind: ApplyTagAction
    tag:
      value: has-session

Strip the Cookie header from a specific host

Force the client to be treated as anonymous on a chosen API to see how it falls back when the server cannot identify the user.

rules:
- filter:
    typeKind: FilterCollection
    operation: And
    children:
    - typeKind: HasAnyCookieOnRequestFilter
    - typeKind: HostFilter
      pattern: api.example.com
      operation: Exact
  actions:
  - typeKind: DeleteRequestHeaderAction
    headerName: cookie

Throttle authenticated traffic only

Slow down requests that carry cookies, leaving public asset fetches at full speed, so you can profile session sensitive endpoints.

rules:
- filter:
    typeKind: HasAnyCookieOnRequestFilter
  actions:
  - typeKind: AverageThrottleAction
    bandwidthBytesPerSeconds: 65536

Reference

hasAnyCookieOnRequestFilter

Description

Select exchanges having any request cookie

Evaluation scope

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

YAML configuration name

hasAnyCookieOnRequestFilter

Settings

This filter has no specific characteristic

The following table describes the customizable properties available for this filter:

Property	Type	Description	DefaultValue
inverted	boolean	Negate the filter result	false

Example of usage

The following examples apply a comment to the filtered exchange

Select exchanges having any request cookie.

rules:
- filter:
    typeKind: HasAnyCookieOnRequestFilter
  actions:
  - typeKind: ApplyCommentAction
    comment: filter was applied

.NET reference

View definition of HasAnyCookieOnRequestFilter for .NET integration.

Frequently asked questions

Does this filter inspect any particular cookie?

No. It only checks whether the request has at least one Cookie header value. If you need to target a named cookie, use hasCookieOnRequestFilter instead.

Will it match an empty Cookie header?

An empty header is treated as having no cookie value, so the filter will not match it. Most clients omit the header entirely when there is nothing to send.

Can I invert it to find anonymous traffic?

Yes. Set inverted: true and the filter will match requests that do not carry a Cookie header.

Learn more about Fluxzy rules

Rule file syntax reference Importing YAML rules into Fluxzy Desktop Using rule files with Fluxzy CLI

Browse all directives