postmanlabs / postmanlabs/postman-code-generators
curl codegen: file-type FormParam contentType ignored — ';type=' not emitted for multipart file parts
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1k
- Forks
- 381
- PR merge metrics
- No merged PRs in 30d
Description
Summary
The curl codegen correctly passes contentType through the preprocessing step for type === 'file' FormParams, but then silently drops it in snippet generation. As a result, -F 'field=@"/path/to/file"' is always emitted without the ;type=<ct> suffix — even when FormParam.contentType is explicitly set.
Steps to reproduce
- Create a Postman request with a
multipart/form-databody. - Add a file-type form param (e.g. key
attachment, src/path/to/file) and setcontentTypetoimage/pngon the param. - Generate the curl snippet.
Expected:
-F 'attachment=@"/path/to/file";type=image/png'
Actual:
-F 'attachment=@"/path/to/file"'
Root cause
In codegens/curl/lib/index.js, the preprocessing loop (≈ line 107) correctly reads contentType = param.contentType and passes it to addFormParam. However, in snippet generation, contentType is only applied in the else (text-type) branch — never in the data.type === 'file' branch:
if (data.type === 'file') {
snippet += `...@"${data.src}"...`;
snippet += quoteType;
// ← contentType never checked here
}
else {
// text params
if (data.contentType) {
snippet += `;type=${data.contentType}`; // ← only lands here
}
snippet += quoteType;
}
curl fully supports ;type= for file parts:
curl -F 'attachment=@"/path/to/file";type=image/png' https://example.com/upload
Suggested fix
Add the same contentType check inside the data.type === 'file' block, before the closing quote:
if (data.type === 'file') {
snippet += `...@"${data.src}"`;
if (data.contentType) {
snippet += `;type=${data.contentType}`;
}
snippet += quoteType;
}
Prior art
PR #418 (merged Nov 2020) introduced ;type= support for text-type form params across several codegens. File-type params were not covered at that time.
Context
Encountered while implementing OAS encoding.contentType support in docusaurus-openapi-docs. When a spec declares per-part content types for multipart/form-data, we set FormParam.contentType accordingly — but the curl snippet never reflects it for binary file fields.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in codegens/curl/lib/index.js at the file-type snippet-generation branch, after reviewing the preprocessing loop around line 107. Trace how FormParam.contentType reaches addFormParam and compare the file and text branches. Done means a file param with contentType image/png emits the ;type=image/png suffix in the curl multipart form part.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100