Multipart Part Length Consistency Audit

Description

Compare explicit declared and observed part byte counts with signed discrepancies; does not parse Content-Length headers, bodies or transfer encodings.

A media type has a type/subtype token and may carry named parameters. Multipart content uses explicit boundary delimiter lines around its parts. Token case rules, parameter quoting, repeated records and exact line endings affect how a representation is interpreted; a lexical check is narrower than parsing a complete message.^[1]

Compare explicit declared and observed part byte counts with signed discrepancies; does not parse Content-Length headers, bodies or transfer encodings.

When to use this tool

Use this tool to compare explicit declared and observed part byte counts with signed discrepancies; does not parse Content-Length headers, bodies or transfer encodings.

How to use the tool and how it works

Enter declaredLengths, actualLengths using the field definitions below.
Run the operation. Correct input errors before interpreting an output.
Read result.differences, result.matches. Use the ordering, boundary rules and absence conditions described below.

Require aligned nonnegative integer declared and actual lengths. Return actual minus declared and an equality flag for each pair.^[2]

Input field	Meaning and units	Accepted input
declaredLengths	Declared nonnegative integer part lengths in bytes.	Dense list of at most 128 finite numbers; integer/shape constraints above also apply.
actualLengths	Supplied actual nonnegative integer part lengths in bytes, aligned with declaredLengths.	Dense list of at most 128 finite numbers; integer/shape constraints above also apply.

Output field	Interpretation
result	Object containing the named fields below.
result.differences	Actual minus declared byte counts for aligned parts.
result.matches	Per-part flags for exact equality of actual and declared lengths.

json

{
  "input": {
    "declaredLengths": [
      3,
      4
    ],
    "actualLengths": [
      3,
      2
    ]
  },
  "output": {
    "result": {
      "differences": [
        0,
        -2
      ],
      "matches": [
        true,
        false
      ]
    }
  }
}

Limitations and assumptions

Lengths are supplied rather than measured from a payload; a match does not validate a MIME part.
Supported boundary strings contain 1–70 characters from the declared MIME boundary subset and cannot end in a space. Single-byte envelope budgets are distinct from UTF-8 text byte counts and from a complete MIME transport.
Every declared top-level input field is required and unexpected fields are rejected. Ordinary strings are limited to 8,192 UTF-16 code units and lists to 128 entries, with tighter operation-specific bounds where stated. JSON text has bounded nesting and node counts.
Numeric outputs must be finite and no larger in absolute magnitude than the safe-integer limit; operations returning exact large integers use decimal text. Positions are zero-based and spans end exclusively unless the operation explicitly states a different convention.

Alternative or Complementary methods

Choose the target media-type and multipart conventions explicitly. Use a complete MIME parser for nested messages and encodings; these record and delimiter tools handle only their stated representations.

References

RFC 2046: MIME Media Types — RFC Editor
Tool behavior and example: Multipart Part Length Consistency Audit — tool.io

Similar or alternative tools

Multipart Part Envelope Byte Budget
Budget one MIME part as opening delimiter, supplied Latin-1 header lines plus blank line, explicit payload byte count and trailing CRLF; excludes final closing delimiter.
Multipart Boundary Delimiter Formatter
Format one RFC 2046 multipart delimiter line with explicit closing policy and CRLF; validates the supplied boundary, does not generate a collision-safe boundary.