postmanlabs / postmanlabs/postman-code-generators

curl codegen: file-type FormParam contentType ignored — ';type=' not emitted for multipart file parts

Open Beginner friendly
#815 2 comments 0 reactions 0 assignees View on GitHub

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

  1. Create a Postman request with a multipart/form-data body.
  2. Add a file-type form param (e.g. key attachment, src /path/to/file) and set contentType to image/png on the param.
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.