Skip to content

Support for multipart/related content type (RFC 2387) #1240

@lanej

Description

@lanej

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions