multipartDataRequestFilter is the dedicated selector for file uploads and other multipart submissions in a Fluxzy rule. It reads the request Content-Type header and matches every request that carries a multipart/form-data body. Use it whenever you want to debug, throttle or audit the upload side of your application.
Reach for multipartDataRequestFilter when a rule should only apply to requests carrying a multipart/form-data body. This is the wire format used by browsers for file uploads, by curl with -F, and by HTTP clients sending rich forms.
Typical situations:
The filter evaluates on the requestHeaderReceivedFromClient scope, so the Content-Type header is already parsed when it fires. Combine it with pathFilter to scope to a specific upload endpoint.
Slow down every multipart upload heading to /api/uploads to reproduce a customer report about timeouts on weak connections.
rules:
- filter:
typeKind: FilterCollection
children:
- typeKind: MultipartDataRequestFilter
- typeKind: PathFilter
pattern: /api/uploads
operation: StartsWith
actions:
- typeKind: AverageThrottleAction
bandwidthBytesPerSeconds: 16384
Apply a tag to all file upload requests so they group together in the Fluxzy capture view, making it easier to audit user submissions.
rules:
- filter:
typeKind: MultipartDataRequestFilter
actions:
- typeKind: ApplyTagAction
tag:
value: file-upload
Return a canned 413 response for every multipart submission to a path that should no longer accept uploads, useful when sunsetting an upload feature.
rules:
- filter:
typeKind: FilterCollection
children:
- typeKind: MultipartDataRequestFilter
- typeKind: PathFilter
pattern: /legacy/upload
operation: StartsWith
actions:
- typeKind: RejectWithStatusCodeAction
statusCode: 413
Select request sending 'multipart/form-data' body. Filtering is made by inspecting value of Content-Type 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
multipartDataRequestFilter
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 |
The following examples apply a comment to the filtered exchange
Select exchanges having request header dnt: 1.
rules:
- filter:
typeKind: RequestHeaderFilter
headerName: dnt
pattern: 1
operation: Exact
actions:
- typeKind: ApplyCommentAction
comment: filter was applied
Select exchanges issued by Chrome 112 by checking User-Agent.
rules:
- filter:
typeKind: RequestHeaderFilter
headerName: User-Agent
pattern: 'Chrome/112 '
operation: Contains
actions:
- typeKind: ApplyCommentAction
comment: filter was applied
View definition of MultipartDataRequestFilter for .NET integration.
This filter has no related filter
It inspects the request Content-Type header. Any value starting with multipart/form-data matches, including those carrying the boundary parameter like multipart/form-data; boundary=----WebKitFormBoundary...
No. multipartDataRequestFilter only checks the Content-Type header, it does not decode the body. Use a custom .NET filter if you need to inspect individual parts or file names.
Yes. Any form with a file input, but also forms that mix text fields with binary data, use multipart/form-data. SOAP attachments and some webhook payloads also rely on multipart.
multipartDataRequestFilter matches application/multipart/form-data, used when a request includes files or binary data. formUrlEncodedRequestFilter matches application/x-www-form-urlencoded, used for plain text form fields only.