Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Submit An Array of Integer Elements In formdata #4741

Closed
Crackz opened this issue Jul 18, 2018 · 11 comments
Closed

Submit An Array of Integer Elements In formdata #4741

Crackz opened this issue Jul 18, 2018 · 11 comments

Comments

@Crackz
Copy link

Crackz commented Jul 18, 2018

Swagger sends the field location (array) as a single value

formdataArray

/signup: {
        post: {
          tags: ['Authentication'],

          requestBody: {
            required: true,
            content: {
              'multipart/form-data': {
                schema: {
                  type: 'object',
                  properties: {
                    ...schema.CreateUserBody.properties,
                    location: {
                      type: 'array',
                      items: {
                        type: 'integer'
                      },
                      example: [32.3046505, 30.6080822]
                    },
                    profileImg: {
                      type: 'string',
                      format: 'binary'
                    },
                  },

                }
              }
            }
          },
          responses: {
            201: {
              description: 'User Created',
              content: {
                'application/json': {
                  // schema:{
                  //   $ref: '#/components/schemas/User'
                  // }
                }
              }
            }
          }
        },
      }

i expected that the field(location) will be repeated for each element in the array

how would i make it work this way ?

@hkosova
Copy link
Contributor

hkosova commented Jul 18, 2018

@Crackz So you want a multipart request with duplicate field names?

POST /signup
Content-Type: multipart/form-data; boundary=acb

--acb
Content-Disposition: form-data; name="location"

2112
--acb
Content-Disposition: form-data; name="location"

3232
--acb
Content-Disposition: form-data; name="location"

1234
--acb--

OpenAPI 3.0 Specification says this will be the case when uploading an array of files:

requestBody:
  content:
    multipart/form-data:
      schema:
        properties:
          # The property name 'file' will be used for all files.
          file:
            type: array
            items:
              type: string
              format: binary

but I'm not sure if this is supported for arrays of primitives. @webron do you happen to know this? Exploded arrays location=2112&location=3232 is the default array style for application/x-www-form-urlencoded requests in OAS 3, but it's not clear if exploded arrays can be defined for multipart.

@Crackz
Copy link
Author

Crackz commented Jul 18, 2018

@hkosova yes exactly

Specification

If the property is a primitive, or an array of primitive values, the default Content-Type is text/plain

but i can't find a way to change this behavior and also tried style and explode but failed to make it work.

@webron
Copy link
Contributor

webron commented Jul 18, 2018

Thanks for bringing up the question, and this is indeed a bug.

There some subtle differences when the spec is referring to application/x-www-form-urlencoded requests vs multipart/* requests. For the former, this summarizes it.

To further control how these request bodies are serialized, we also introduced the Encoding Object which has support for style, explode, and allowReserved, all of which are only supported for application/x-www-form-urlencoded. If you follow the documentation further you'll see that the default behavior is the same as query parameters, where the default is that the style is form and explode is true. That means that unless defined otherwise, the array value should be exploded into multiple instances - hence the bug.

@webron
Copy link
Contributor

webron commented Aug 23, 2018

@hkosova was kind enough to point out to me that I was completely missed the point and was talking... somewhat nonsense. I kept talking about application/x-www-form-urlencoded but the issue is actually with multipart/form-data.

From reading the spec, I don't see a clear way to define what you're looking for, @Crackz, so I'd suggest filing a ticket with the spec itself. At the moment, there's nothing we can do more to solve this.

@xanoinc
Copy link

xanoinc commented Aug 27, 2018

I just ran into this bug as well. My case is with application/x-www-form-urlencoded. I think the issue is related to the requestBody section.

I am attaching an example where explode is set to true in both the parameter block and the requestBody and they behave differently.

The example midway down this page mentions that you can specify the explode param in the encoding block for the requestBody - https://swagger.io/docs/specification/describing-request-body/

I'm using that exact example, except setting explode to true.

0

{
  "openapi" : "3.0.0",
  "info" : {
    "version" : "1.0.0",
    "title" : "Swagger Petstore",
    "license" : {
      "name" : "MIT"
    }
  },
  "servers" : [ {
    "url" : "http://petstore.swagger.io/v1"
  } ],
  "paths" : {
    "/pets" : {
      "post" : {
        "summary" : "Create a pet",
        "operationId" : "createPets",
        "tags" : [ "pets" ],
        "parameters" : [
          {
            "name" : "limit",
            "in" : "query",
            "description" : "How many items to return at one time (max 100)",
            "required" : false,
            "schema" : {
              "type" : "array",
              "items" : {
                "type": "string"
              }
            },
            "style": "form",
            "explode": true
          }
        ],
        "requestBody" : {
          "content" : {
            "application/x-www-form-urlencoded" : {
              "schema" : {  
                "type" : "object",
                "properties" : {
                  "color" : {
                    "type" : "array",
                    "items" : {
                      "type" : "string"
                    }
                  }
                }
              },
              "encoding" : {
                "color" : {
                  "style" : "form",
                  "explode" : true
                }
              }
            }
          }
        },
        "responses" : {
          "201" : {
            "description" : "Null response"
          }
        }
      }
    }
  }
}

@webron
Copy link
Contributor

webron commented Aug 27, 2018

@seanmetrix since it's a different media type, it's a different issue than the OP. Please file a new ticket so we can work on it separately.

@hkosova
Copy link
Contributor

hkosova commented Jul 3, 2020

@Crackz the next version of the spec, OpenAPI 3.1, will support exploded arrays in multipart/form-data requests, and this is the default serialization style for arrays in form data (i.e. style: form + explode: true).

@Crackz
Copy link
Author

Crackz commented Jul 3, 2020

i will try it when gets supported
thanks for keeping me up !

@mma5997
Copy link

mma5997 commented Mar 16, 2021

In this comment above, I can see that the array types have "Add Item button", but its now showing what type of array is it... here its of type string.

I am facing a same issue at my end.
Please can anyone point me to which version its fixed because if I paste the same JSON in editor.swagger.io I can see it as "Add string item".
Thanks :)

@mathis-m
Copy link
Contributor

@mma5997 I added the type label and support for nested arrays with v3.44.1. json schema array items (#7007) (2016c18)

@mma5997
Copy link

mma5997 commented Mar 22, 2021

Thanks @mathis-m, will test with the dist of that version and get back if any concerns :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants