Generated CURL seems wrong for mime/multipart uploads that have JSON parts - missing 'type=' option, wrong quotes.

[shockey]

From @dvelitchkov on August 21, 2018 0:15

Running swagger editor from docker container, no customizations.

Q&A (please complete the following information)

• OS: macOS
• Browser: chrome
• Version: 68.0.3440.106
• Method of installation: docker
• Swagger-Editor version: latest
• Swagger/OpenAPI version: OpenAPI 3.0

Content & configuration

Example Swagger/OpenAPI definition:

openapi: '3.0.0'
info:
  title: "Foo"
  version: 1.0.0
  
servers:
  - url: https://foo/v1/api
    
paths:
  /upload/:
    post:
      tags:
      - "upload"
      operationId: "upload"

      requestBody:
        required: true
        content: 
          multipart/form-data: # Media type
            schema:
              type: object
              properties: # Request parts
                file:
                  type: string
                  format: binary
                options:
                  type: object
                  properties:
                    some_array:
                      type: array
                      items:
                        type: string
                    max_bar:
                      type: integer
                      default: 300
                    
      responses:
        '200':
          description: ok
          content:
            application/json:
              schema:
                type: object
                properties: 
                  foo:
                    type: string

Describe the bug you're encountering

The generated CURL looks like this:

curl -X POST "https://foo/v1/api/upload/" -H "accept: application/json" -H "Content-Type: multipart/form-data" -F "options={ "some_array": [ "string" ], "max_bar": 0 }" -F "myfile=@bla;type=application/zip"

Expected behavior

I think there are two issues here:

1. The "type=" option tha specifies the content-type for the "options" part is missing - I feel it should be "application/json", since that is the default for "objects". The "type=" option is actually present for the "myfile" part, which is great.

2. The quotes for the "options" part need to be single quotes, e.g. -F 'options={ "some_array": [ "string" ], "max_bar": 0 }', not -F "options={ "some_array": [ "string" ], "max_bar": 0 }", as having double-quotes everywhere will just cause the shell to strip them.

Additional context or thoughts

The full correct curl should be:

curl -X POST "https://foo/v1/api/upload/" -H "accept: application/json" -H "Content-Type: multipart/form-data" -F 'options={ "some_array": [ "string" ], "max_bar": 0 };type=application/json' -F "myfile=@bla;type=application/zip"

Copied from original issue: swagger-api/swagger-editor#1871

[LouCastaldo]

Same issue here with both "multipart/mixed" and "multipart/form-data". Both generate incorrect cURL command. Any progress on correcting this ??

[char0n]

Hi everybody,

Related to second point from the Expected Behavior looks like that has already been fixed. Here is the POC generated from the definition of this issue description.

2. The quotes for the "options" part need to be single quotes, e.g. -F 'options={ "some_array": [ "string" ], "max_bar": 0 }', not -F "options={ "some_array": [ "string" ], "max_bar": 0 }", as having double-quotes everywhere will just cause the shell to strip them.

curl -X 'POST' \
  'https://foo/v1/api/upload/' \
  -H 'accept: application/json' \
  -H 'Content-Type: multipart/form-data' \
  -F 'file=@file.pdf;type=application/pdf' \
  -F 'options={
  "some_array": [
    "string"
  ],
  "max_bar": 300
}'

Provided test case in #9096

[char0n]

Hi everybody,

Related to first point - missing mime type for individual boundaries:

The "type=" option tha specifies the content-type for the "options" part is missing - I feel it should be "application/json", since that is the default for "objects". The "type=" option is actually present for the "myfile" part, which is great.

This issue needs to be addressed both in SwaggerUI (here) and in SwaggerClient. OpenAPI 3.x.y specification allows to fully influence this by using encoding field of Media Type Object.

---

For SwaggerClient, PR has been issued to address this and respect the encoding field: swagger-api/swagger-js#3078.

Description

OpenAPI 3.x.y definition:

{
  "openapi": "3.0.0",
  "paths": {
    "/upload/": {
      "post": {
        "tags": [
          "upload"
        ],
        "operationId": "upload",
        "requestBody": {
          "required": true,
          "content": {
            "multipart/form-data": {
              "schema": {
                "type": "object",
                "properties": {
                  "options": {
                    "type": "object",
                    "properties": {
                      "some_array": {
                        "type": "array",
                        "items": {
                          "type": "string"
                        }
                      },
                      "max_bar": {
                        "type": "integer",
                        "default": 300
                      }
                    }
                  }
                }
              },
              "encoding": {
                "options": {
                  "contentType": "application/json; charset=utf-8"
                }
              }
            }
          }
        }
      }
    }
  }
}

Here is how the multipart/form-data request looked BEFORE:

POST / HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------9051914041544843365972754266

-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="options"

{"some_array":["string"],"max_bar":300}

Here is how the multipart/form-data request looked AFTER:

POST / HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------9051914041544843365972754266

-----------------------------9051914041544843365972754266
Content-Disposition: form-data; name="options"; filename="blob"
Content-Type: application/json

{"some_array":["string"],"max_bar":300}

Every boundary now contains specific Content-Type header if defined. Note that filename is also present in every Content-Disposition header and always contains value of blob. This inclusion of filename cannot be avoided as this is the only way how to assign specific Content-Type for every boundary.

---

For SwaggerUI this issue has been addressed in #9105

CURL command correctly generated by assigning additional type=:

[char0n]

Addressed by #9105

[Saljack]

This is not fixed. The PR #9105 added support only if you add an encoding . Updated working example with encoding

            schema:
              type: object
              properties: # Request parts
                file:
                  type: string
                  format: binary
                options:
                  type: object
                  properties:
                    some_array:
                      type: array
                      items:
                        type: string
                    max_bar:
                      type: integer
                      default: 300
            encoding:
              options: # Property name
                contentType: application/json   

But it should be content type application/json by default see https://swagger.io/docs/specification/describing-request-body/multipart-requests/
and there is:

By default, the Content-Type of individual request parts is set automatically according to the type of the schema properties that describe the request parts:

Schema Property Type	Content-Type
Primitive or array of primitives	text/plain
Complex value or array of complex values	application/json
String in the binary or base64 format	application/octet-stream