Validate Multipart Form Data at the Exact Body Byte Boundary

Use this procedure when a multipart form request has semantic limits on Unicode text fields and a separate byte ceiling on the complete request body. The byte decision must include the actual multipart structure, not only the UTF-8 bytes of the submitted strings.

This procedure applies to the body representation named by the contract. Transport headers are excluded unless the contract explicitly includes them. Transfer framing or content coding is included only when the byte ceiling is defined after that stage.

Freeze the contracts

Record these details before validating:

• The semantic unit for each limited text field: grapheme clusters, Unicode code points, or a contractually named code-unit scheme.
• Any required normalization and whether it occurs before semantic counting and encoding.
• The charset used for each text part.
• The exact byte-limited representation, such as the uncompressed multipart body or the compressed transport body.
• Whether the byte maximum is inclusive.
• How the boundary token is chosen and whether it is fixed before measurement.
• The production rules for line endings, part ordering, repeated names, optional headers, filename parameters, and final delimiters.
• Whether file parts carry raw bytes or pass through another encoding.

Do not convert the body byte ceiling into a character allowance. A text value can pass its semantic limit while its encoded part, headers, and surrounding delimiters push the complete body over the byte ceiling.

Validate text semantics independently

For every text field:

1. Apply only the normalization required by the contract.
2. Count the declared Unicode unit on the declared value.
3. Reject a semantic violation with the field identifier, unit, measured count, and limit.
4. Preserve that decision separately from body-size validation.

A file length, multipart header length, or remaining body budget must not change whether a text field satisfies its semantic rule.

Freeze one production multipart encoding

Choose the actual boundary before measuring. Build parts with the same production encoder and settings that will be used for transmission.

The measured byte stream must account for every emitted component:

• Opening and inter-part boundary delimiters.
• Required carriage-return and line-feed sequences.
• Every per-part header and header terminator.
• The exact encoding of text values.
• Raw file bytes or the contractually required transformed file bytes.
• Separators after part content.
• The closing boundary delimiter and any final line ending actually emitted.

Filename and name parameters deserve special attention. Non-ASCII parameter encoding, quoting, escaping, or fallback parameters can add bytes even when the corresponding field value is unchanged.

Measure and send the same representation

Use one of these patterns:

• Materialize the complete body once, read its byte length, retain it, and send those exact bytes.
• Stream through a counting sink that enforces the remaining budget while writing the identical bytes to the transport or to retained chunks.

For a bounded counter, compare each next segment length with the remaining allowance before adding it. This avoids overflow in an accumulated total and lets the encoder stop before reading or buffering unnecessary file content.

Do not perform a dry-run encoding and then rebuild the multipart body with a new random boundary, different header choices, reordered parts, changed metadata, or a different charset. If rebuilding is unavoidable, freeze all inputs and encoder decisions and verify that the transmitted byte count equals the measured count.

Derive Content-Length from the retained body bytes when that header is used. With chunked transfer, continue to enforce the declared multipart-body limit; count chunk framing only if the contract explicitly places the ceiling at that transport layer.

Keep failures distinct

Report separate outcomes for:

• A text field exceeding its semantic Unicode limit.
• The complete multipart body exceeding its byte ceiling.
• A single file or part exceeding a separately declared part limit.
• Multipart serialization or text encoding failing.
• A caller-supplied Content-Length disagreeing with the bytes selected for transmission.

Useful diagnostics include the named byte boundary, measured or lower-bound size, limit, part count, and safe part identifier. Do not log rejected text or file contents merely to explain their size.

Reasoned example

The following calculation is reasoned, not an executed test.

Assume a multipart body uses boundary token b, carriage-return and line-feed line endings, one text part named name, a UTF-8 content type header, and a final line ending after the closing delimiter. The body shape is:

--b
Content-Disposition: form-data; name="name"
Content-Type: text/plain; charset=utf-8

VALUE
--b--

The displayed lines represent carriage-return and line-feed delimiters even if a renderer shows ordinary newlines.

Under those assumptions, all structure other than VALUE occupies one hundred two bytes. If VALUE is ASCII A, the complete body occupies one hundred three bytes. If VALUE is the grinning-face character, the complete body occupies one hundred six bytes because that single Unicode code point occupies four UTF-8 bytes.

Both values contain one code point. Therefore, under an inclusive one-code-point field limit and a one-hundred-four-byte body ceiling, both pass the semantic rule, the ASCII body fits, and the grinning-face body does not. These counts depend on the stated boundary, headers, and final line ending; they are not evidence about a different encoder.

Verification checklist

Execute implementation tests before claiming runtime evidence:

• A text field lands exactly on its semantic limit while the complete body lands exactly on the byte ceiling.
• A one-code-point multibyte value passes semantics but makes the body exceed the ceiling.
• A semantic violation is rejected even when the body would fit.
• Adding only a part header, quoted parameter, or final delimiter crosses the body ceiling.
• Non-ASCII filenames exercise the production parameter-encoding path.
• An empty text part and an empty file part still include their full structural overhead.
• A large file is stopped by the remaining byte budget without integer overflow.
• The boundary used for measurement is the boundary used for transmission.
• The measured body bytes, transmitted body bytes, and Content-Length agree when Content-Length is present.
• Alternate part order or optional headers are either frozen or measured as distinct bodies.
• If compression or transfer framing is in scope, tests measure the specifically contracted stage.

Until these tests are run, describe sizes and outcomes only as reasoned expectations.

Supporting basis and limitations

The procedure is derived from multipart byte structure, UTF-8 encoding widths, and the independence of semantic Unicode rules from aggregate wire-size limits. The example is a reasoned calculation. No executable tests, packet captures, runtime observations, external sources, conversation evidence, or review approval were used.

Existing guidance located by bounded search covers independent semantic and byte validation, crossed fixtures, streaming UTF-8, URI percent encoding, and whole serialized batches. It does not state the narrower multipart procedure for freezing a generated boundary and accounting for per-part headers, line endings, file bytes, and the closing delimiter.