[Kludex]

MultipartParser didn't recognise a delimiter with spaces or tabs between the boundary and its CRLF. The delimiter line and the next part were delivered as data of the part already open, so two parts came out as one.

RFC 2046 §5.1.1 allows this transport padding and says receivers must be able to handle it. Werkzeug, Django and the standard library email parser all return two parts for these requests.

Line after a part	Before	After
--boundary \t\r\n	Data	New part
--boundary foo	Data	MultipartParseError
--boundaryX	Data	Data

A line starting with the boundary can't be part data under the RFC, so a boundary followed by spaces or tabs and then anything other than CRLF now raises an error. A padded opening boundary is still rejected, as it is today.

AI Disclaimer

This PR was developed with the assistance of either Claude or Codex. I've reviewed and verified the changes.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-01T07:10:46.319683Z	beff395	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[codspeed]

Merging this PR will not alter performance

✅ 5 untouched benchmarks

---

_{Comparing handle-boundary-padding (beff395) with main (66e4fa4)}

[cubic-dev-ai]

No issues found across 4 files

_{View guided diff | Re-trigger cubic}