-
Notifications
You must be signed in to change notification settings - Fork 112
Open
Description
Summary
Progenitor doesn't support multipart/related content type, required by Google Workspace APIs (Drive, Gmail) for uploads combining JSON metadata with binary content. This is distinct from multipart/form-data (issue #518).
Use Case
Google Drive API uploads use multipart/related:
POST /upload/drive/v3/files?uploadType=multipart
Content-Type: multipart/related; boundary=foo_bar_baz
--foo_bar_baz
Content-Type: application/json; charset=UTF-8
{"name": "document.txt", "mimeType": "text/plain"}
--foo_bar_baz
Content-Type: text/plain
[file content]
--foo_bar_baz--Key difference from multipart/form-data: Uses Content-ID references instead of field names, no Content-Disposition headers required (RFC 2387 vs RFC 7578).
Current Error
requestBody:
content:
multipart/related:
schema:
type: object
properties:
metadata: {$ref: '#/components/schemas/FileMetadata'}
file: {type: string, format: binary}Error: UnexpectedFormat("unexpected content type: multipart/related")
Current Workaround
Using application/octet-stream with manual multipart construction loses:
- OpenAPI contract for request structure
- Type safety for metadata schema
- Request validation
Desired Generated Code
client
.upload_file_multipart()
.metadata(FileMetadata { name: "doc.txt".to_string(), ... })
.file(file_bytes)
.send()
.await?Impact
Affects Rust clients for:
- Google Workspace APIs (Drive, Gmail, etc.) - major enterprise use case
- Any API using RFC 2387 for compound documents
We're happy to test implementations and provide additional examples!
References
- RFC 2387: https://www.ietf.org/rfc/rfc2387.txt
- Google Drive API: https://developers.google.com/drive/api/guides/manage-uploads
- Related: content multipart/form-data is not supported #518, impl "multipart/form-data" support #418 (multipart/form-data)
Metadata
Metadata
Assignees
Labels
No labels