Problem
turnloop_http::client has no multipart form builder — no Form/Part type, no boundary generation, no multipart/form-data encoder at all. A host that needs to send a multipart body (file upload, form fields) has to write RFC 2046/7578 framing itself.
Why it matters
This is the concrete blocker for Perry's CLI migration off reqwest. perry publish, perry audit, perry verify and perry run --remote all send multipart bodies (three of the four send base64-encoded fields), and reqwest::multipart was the only thing on the old transport doing this. P8 recorded the gap; P11 — the lane that actually replaced reqwest in the perry CLI with a turnloop-based client — had to write its own builder rather than route around it: crates/perry-http-client/src/multipart.rs, 280 lines, which the lane's own report says "wants to be in turnloop-http, next to the chunked encoder."
The part of that builder worth folding in, not just the boundary-writing mechanics: the boundary has to be verified absent from every part's bytes, not merely drawn from entropy, because a base64-encoded field can contain a boundary-shaped substring and a collision silently truncates the upload. Perry's version scans every part's bytes and regenerates until the chosen boundary does not occur in any of them (the_chosen_boundary_never_occurs_inside_a_part plants a boundary-shaped string as a payload and asserts the delimiter still appears exactly twice — once opening, once closing).
What would fix it
A multipart module next to http1::Encoder: text fields and named file parts, boundary generation with a collision check against the assembled parts. In-memory (not streaming) is enough to match every current Perry caller — reqwest::multipart::Part::stream appears nowhere in the callers this replaces, only Part::text.
Problem
turnloop_http::clienthas no multipart form builder — noForm/Parttype, no boundary generation, nomultipart/form-dataencoder at all. A host that needs to send a multipart body (file upload, form fields) has to write RFC 2046/7578 framing itself.Why it matters
This is the concrete blocker for Perry's CLI migration off
reqwest.perry publish,perry audit,perry verifyandperry run --remoteall send multipart bodies (three of the four send base64-encoded fields), andreqwest::multipartwas the only thing on the old transport doing this. P8 recorded the gap; P11 — the lane that actually replacedreqwestin theperryCLI with a turnloop-based client — had to write its own builder rather than route around it:crates/perry-http-client/src/multipart.rs, 280 lines, which the lane's own report says "wants to be in turnloop-http, next to the chunked encoder."The part of that builder worth folding in, not just the boundary-writing mechanics: the boundary has to be verified absent from every part's bytes, not merely drawn from entropy, because a base64-encoded field can contain a boundary-shaped substring and a collision silently truncates the upload. Perry's version scans every part's bytes and regenerates until the chosen boundary does not occur in any of them (
the_chosen_boundary_never_occurs_inside_a_partplants a boundary-shaped string as a payload and asserts the delimiter still appears exactly twice — once opening, once closing).What would fix it
A
multipartmodule next tohttp1::Encoder: text fields and named file parts, boundary generation with a collision check against the assembled parts. In-memory (not streaming) is enough to match every current Perry caller —reqwest::multipart::Part::streamappears nowhere in the callers this replaces, onlyPart::text.