Many failure modes are easier to reproduce with the proxy than with a real service. rejectWithStatusCodeAction is the smallest tool for the job: pick a status code, scope the filter, and Fluxzy will return that code consistently for as long as the rule is active.
rejectWithStatusCodeAction lets you decide exactly which HTTP status code the client receives when the rule matches. The body is the standard reason phrase, which is enough for most simulation and blocking scenarios.
Reach for it when:
When the client expects a structured body, rejectWithMessageAction is a better fit. For a flat 403, use rejectAction.
Confirm that a client correctly retries or falls back when its upstream service appears to be down. No upstream traffic is generated.
rules:
- filter:
typeKind: HostFilter
pattern: api.internal.example.com
actions:
- typeKind: RejectWithStatusCodeAction
statusCode: 502
Useful when you want to test behaviour against a missing endpoint without removing the deployment. Combine with a path filter to scope the simulated 404.
rules:
- filter:
typeKind: FilterCollection
operation: And
children:
- typeKind: HostFilter
pattern: api.internal.example.com
- typeKind: PathFilter
pattern: ^/v2/users/42
actions:
- typeKind: RejectWithStatusCodeAction
statusCode: 404
Trigger client side back off logic by returning 429 for a chosen endpoint without provisioning a real rate limiter.
rules:
- filter:
typeKind: PathFilter
pattern: ^/api/v1/search
actions:
- typeKind: RejectWithStatusCodeAction
statusCode: 429
Block the request and return a custom HTTP error response. Allows specifying the status code (e.g., 403, 404, 502) to return to the client. The response body will contain the standard reason phrase for the status code.
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
rejectWithStatusCodeAction
This action has no specific characteristic
The following examples apply this action to any exchanges
Block with 404 Not Found (hide resource existence).
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: RejectWithStatusCodeAction
statusCode: 404
Block with 502 Bad Gateway (simulate server unavailability).
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: RejectWithStatusCodeAction
statusCode: 502
View definition of RejectWithStatusCodeAction for .NET integration.
The following actions are related to this action:
The action returns the standard reason phrase as the body. For a custom payload, use rejectWithMessageAction. For full control over headers and body, use mockedResponseAction.
Any integer is accepted, but you should stick to valid HTTP status codes so clients react sensibly. Numbers outside the 100 to 599 range may cause client side parsing errors.
That depends entirely on the client. Browsers do not retry 4xx responses, but many SDKs retry 5xx codes with back off. Use this action to test exactly that behaviour.
No. Fluxzy short circuits the exchange right after parsing the client headers, so no bytes leave the proxy.