The `mixpart` library is a high-performance streaming parser for `multipart/mixed` messages in Node.js, designed for optimal memory efficiency and robust error handling. It currently ships as version `0.0.5` and is primarily intended as a private workspace package within a monorepo, implying a stable but internally-focused release cadence rather than frequent public updates. Its key differentiators include true streaming processing where each message payload is exposed as a `ReadableStream`, preventing full buffering of entire parts, and zero memory buffering for message payloads. It also features built-in memory safety configurations to guard against unbounded memory growth from malformed data, optimized search algorithms using Node.js `Buffer.indexOf` for fast boundary detection, and proper ISO-8859-1 header decoding per HTTP standards. The package also provides comprehensive TypeScript support.
npm install mixpartVerified import paths — ran on the pinned version, not inferred.
Demonstrates how to parse a multipart/mixed stream, access headers, and stream the payload of each part. It includes a simulated multipart response for a runnable example.
Avoid direct installation or use unless explicitly instructed by the package maintainers; seek alternative public libraries for general multipart parsing needs.
Always configure `ParserOptions` with appropriate `maxHeaderSize` and `maxBoundaryBuffer` values based on expected input and security requirements when calling `parseMultipartStream`.
Be aware that header values from `message.headers.get()` are ISO-8859-1 decoded. If specific header fields are known to use different encodings (e.g., RFC 2047 encoded-word syntax), additional decoding logic may be required by the application.
Increase the `maxHeaderSize` option in `ParserOptions` if larger headers are legitimately expected, or investigate the source of the multipart data for potential malicious input. Default is 64KB.
Increase the `maxBoundaryBuffer` option in `ParserOptions` if very long or complex boundary patterns are legitimately expected, or, more commonly, inspect the incoming data stream for signs of corruption or malicious attempts to exhaust memory.
No dependency data recorded yet.