feat: add --upload-content-type flag and smart MIME inference for uploads#429
feat: add --upload-content-type flag and smart MIME inference for uploads#429Huglo wants to merge 1 commit intogoogleworkspace:mainfrom
Conversation
…oads The multipart upload media Content-Type is now resolved independently from the metadata mimeType, enabling Drive import conversions (e.g. Markdown → Google Docs) to work automatically. Priority order for the media MIME type: 1. --upload-content-type flag (explicit override) 2. File extension inference (best guess for what the bytes are) 3. Metadata mimeType (backward-compat fallback) 4. application/octet-stream Previously the metadata mimeType was reused for the media part, which meant uploading `notes.md` with mimeType set to `application/vnd.google-apps.document` would incorrectly label the bytes as a Google Doc instead of text/markdown. Made-with: Cursor
🦋 Changeset detectedLatest commit: a4bfb58 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
googleworkspace-bot
added
area: http
area: core
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the file upload functionality by introducing a dedicated flag for specifying the media's content type and implementing intelligent MIME type inference. These changes streamline the process of uploading files to services like Google Drive, particularly for scenarios requiring automatic format conversions, by ensuring the correct content type is communicated for the actual file bytes, independent of the target metadata type. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature for file uploads by adding the --upload-content-type flag and intelligent MIME type inference. The implementation is clean and well-tested, and the separation of concerns in resolve_upload_mime is good. I have one suggestion to improve the robustness of the file extension detection logic to better handle common edge cases like dotfiles.
| let ext = std::path::Path::new(path) | ||
| .extension() | ||
| .and_then(|e| e.to_str())?; |
There was a problem hiding this comment.
The current implementation using std::path::Path::extension doesn't handle dotfiles (e.g., .bashrc, .gitignore) as having an extension, which can lead to incorrect MIME type inference for such files. Using rsplit_once on the filename is more robust and correctly identifies extensions for dotfiles. This ensures that MIME type inference works as expected for a wider range of common file naming conventions.
let ext = std::path::Path::new(path)
.file_name()
.and_then(std::ffi::OsStr::to_str)
.and_then(|name| name.rsplit_once('.'))
.map(|(_, ext)| ext)?;There was a problem hiding this comment.
The divergence only happens for dotfiles with no stem (.md, .bashrc, .gitignore). The two questions are:
- Would rsplit_once actually help? For .bashrc and .gitignore, it would yield bashrc and gitignore — neither of which is in our MIME map, so the result is identical (None → fallback). The only real case is a bare .md or .json file with no name, which is extremely uncommon as an upload target.
- Would it hurt? It could arguably be less correct — .bashrc is conventionally not considered to have an extension; Rust's Path behavior here aligns with POSIX conventions where leading-dot files are hidden files, not extensionless files with a dotted extension.
I would suggest to leave the code as is, but happy to take another point of view.
2 participants
Summary
--upload-content-typeflag for multipart uploads, allowing the mediaContent-Typeto be set independently from the metadatamimeType.md→text/markdown) when the flag is omitted, so Drive import conversions work automaticallymimeTypeonly for unrecognized extensions, preserving backward compatibilityPreviously, uploading
notes.mdwith"mimeType":"application/vnd.google-apps.document"would label the media bytes as a Google Doc. Now the media part correctly getstext/markdown, and Drive performs the Markdown → Google Docs conversion.Test plan
cargo test— 556 tests pass (7 new tests forresolve_upload_mime)cargo clippy -- -D warnings— cleanMade with Cursor