Portman generates wrong Accept header in request when a responce has an empty content type

[theold190]

We have noticed an issue in generated Postman collections if there is a response without content type defined. It seems very similar to issue reported in #392.

Here is an example of a specification, where one of responses has no content (204):

openapi: 3.0.0
info:
  title: Test
  version: '1.0'
paths:
  /test/endpoint:
    post:
      summary: Test endpoint
      responses:
        '204':
          description: 204 description
        '401':
          description: 401 description
          content:
            application/problem+json:
              schema:
                type: string
      requestBody:
        content:
          application/json:
            schema:
              type: string

Generated Postman collection will contain:

      "request": {
        "name": "Test endpoint",
...
        "header": [
          {
            "key": "Content-Type",
            "value": "application/json"
          },
          {
            "key": "Accept",
            "value": "application/problem+json"
          }
        ],
...
      }

Note an "Accept: application/problem+json" in request part of a generated file.

Though if we add at least one responce with "application/json" content (201), then generated Postman collection contains "Accept: application/json".

openapi: 3.0.0
info:
  title: Test
  version: '1.0'
paths:
  /test/endpoint:
    post:
      summary: Test endpoint
      responses:
        '204':
          description: 204 description
        '201':
          description: 201 description
          content:
            application/json:
              schema:
                type: string
        '401':
          description: 401 description
          content:
            application/problem+json:
              schema:
                type: string
      requestBody:
        content:
          application/json:
            schema:
              type: string

Generated Postman collection will contain:

      "request": {
        "name": "Test endpoint",
...
        "header": [
          {
            "key": "Content-Type",
            "value": "application/json"
          },
          {
            "key": "Accept",
            "value": "application/json"
          }
        ],
...
      }

We are using Portman 1.18.0.

Is that an expected behavior?

[thim81]

hi @theold190

We will look into this, since it seems not the default behaviour.
If possible could you share your the Portman config as well? That will allow us to try to reproduce the issue locally.

[theold190]

Thanks for a fast reply.

We are not using any extra configuration. Here is how we execute portman command:

$ portman --local testPortmanBug.yml --output testPortmanBug.json --baseUrl https://some-internal-url
================================================================================
 Local Path:            testPortmanBug.yml
 Output Path:           testPortmanBug.json
 Portman Config:        portman-config.default.json
 Postman Config:        postman-config.default.json
 Environment:           .env
 Inject Tests:          true
 Run Newman:            false
 Newman Iteration Data: false
 Upload to Postman:     false
================================================================================
- Converting OpenApi to Postman Collection
  √ Conversion successful
================================================================================
🚀 Collection written to: testPortmanBug.json 🚀
================================================================================

If I read documentation right, it means we are using default configuration.

Also, there are no extra environment variables defined:

$ env | grep "PORTMAN_"
$

We are running it both on Windows and Linux and get same results.

Please write if you need any more info or if you have questions when reproducing the issue.

[thim81]

hi @theold190

We were able to reproduce the issue.

Behind the scenes Portman is using Postman library openapi-to-postman for doing the initial conversion. It seems like an issue in the library, for which I created a Github item. We will monitor it for feedback and depending on that review the options.

[theold190]

Great! Glad that it is helping to make a better tool and reduce the confusion users might have.

I have subscribed to new issue and if needed can provide more info.