feat(engine): parse_multipart builtin + crypto ec_public_jwk/base64url_decode - #39
Merged
Conversation
…l_decode
parse_multipart(content_type, body) decodes multipart/form-data in handlers,
returning (parts, err) with parts as {name, filename, content_type, data};
binary data round-trips via store_blob. whatsapp-style media upload now
accepts the real Cloud API multipart shape with real sha256/file_size and a
byte-exact GET /v21.0/{media_id}/content download endpoint.
crypto.ec_public_jwk serves ES256 JWKS params {kty,crv,x,y}; base64url_decode
inverts base64url_encode for reading JWT segments.
…tion - parse_multipart uses NextRawPart so a Content-Transfer-Encoding header cannot silently transform part bytes (raw-bytes contract). - whatsapp upload requires messaging_product=whatsapp, 400 with Meta #100 otherwise — the most common real Cloud API client mistake. - mime resolution: a generic octet-stream part Content-Type (curl/Go SDK default) no longer masks the real type; prefer mime-like type field, then filename extension. Legacy JSON path honors its type field again.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The 2026-08 fidelity sweep (91 adapters, 603 gaps) flagged multipart/form-data as an explicit engine blocker in 6 adapters (onfido, jumio, whatsapp, cloudflare, drive, pinata): document/photo/binary uploads fell back to JSON shims or discarded bytes. Also adds the two small crypto gaps needed by the ES256 auth adapters: EC JWK export and base64url decode.
What
parse_multipart(content_type, body)— pure Starlark builtin (likepaginate), returns(parts, err); each part is{name, filename, content_type, data}withdatacarrying raw bytes (Starlark strings are byte strings → binary round-trips viastore_blob).erras a value lets handlers answer 400 instead of surfacing 500.crypto.ec_public_jwk(pub_pem)→{kty, crv, x, y}(base64url, fixed 32-byte coords) — ES256 JWKS counterpart torsa_public_jwk(Sign in with Apple, APNs, Search Ads).crypto.base64url_decode(s)— inverse ofbase64url_encode, padding-tolerant (JWT segments).sha256/file_size; newGET /v21.0/{media_id}/contentserves the stored bytes byte-exact at the original mime type (the metadataurlpoints at it, so SDK download flows work). Legacy JSON upload path preserved.Tests
TestParseMultipart{FieldsAndFile,EmptyBody,BadContentType}— runtime builtin unit tests incl. binary round-trip.TestECPublicJWK,TestBase64URLDecodeRoundTrip— crypto.TestWhatsAppStyleMultipartMedia— end-to-end: multipart upload → metadata reflects real bytes → byte-exact download.go test ./...green; gofmt/vet clean;stunt adapter lintclean.Closes stunt-l3l (engine part; onfido/jumio/cloudflare/drive/pinata wiring follows in their adapter slices).