Handle transport padding after multipart boundaries
Merged
KL
5d ago+50+50+01234567890123456789-0-0-0123456789
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.