Fix base64 multipart uploads with line breaks

[justadityaraj]

Fixes #1120.

Problem

Base64 multipart bodies may contain CRLF line wrapping. Formidable counted those characters when choosing four-character decode chunks, so decoded file data could be truncated or corrupted.

Fix

Remove CRLF from base64 data before calculating the next quartet boundary. The multipart integration regression covers a line-wrapped base64 upload and verifies its decoded bytes.

User impact

Line-wrapped base64 uploads now preserve their original file contents.

Verification

• node --experimental-vm-modules ./node_modules/jest/bin/jest.js --runInBand test/standalone/content-transfer-encoding.test.js — 2 tests passed, including the new regression.
• node --test ./test-node/**/*.test.js — 11 tests passed.
• node ./node_modules/eslint/bin/eslint.js --quiet src/plugins/multipart.js — passed.
• node ./node_modules/prettier/bin-prettier.js --check src/plugins/multipart.js test/standalone/content-transfer-encoding.test.js — passed.
• pnpm run build-package — Rollup build passed.
• Full Jest suite — 82 passed; 10 failures are limited to existing Windows path expectations and an ECONNRESET assertion outside the changed files.

Greptile Summary

This PR corrects streaming base64 multipart decoding by removing CRLF line wrapping before calculating complete decode quartets.

• Normalizes base64 part chunks by stripping carriage returns and line feeds before buffering and decoding.
• Adds an integration regression that parses a line-wrapped base64 file upload and verifies the decoded bytes.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/plugins/multipart.js	Strips CRLF characters from streamed base64 part data before calculating quartet boundaries, preserving decoded upload contents.
test/standalone/content-transfer-encoding.test.js	Adds an end-to-end multipart regression covering a line-wrapped base64 file upload.

_{Reviews (3): Last reviewed commit: "Merge branch 'master' into fix/base64-cr..." | Re-trigger Greptile}

[GrosSacASac]

Why are you using a regex instead of a string ?

[justadityaraj]

Because this is streaming input: \r and \n can arrive in separate parser chunks, and the body may contain multiple line breaks. A string replacement would remove only the first complete \r\n pair; replaceAll() is also unavailable on the supported Node 14.0.0. /[\r\n]/g removes every line-break byte independently while preserving that compatibility.

[GrosSacASac]

But formidable project only supports node lts

[justadityaraj]

But formidable project only supports node lts

right, updated in fc38c60 to use separate string replacements for \r and \n preserving split chunk handling

[tunnckoCore]

@justadityaraj thanks.

---

weird.. why i need to approve workflow runs for prs? ooh.. i think i touched a setting recently, ha. 😆