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

File upload on the V3 spec through multipart/form-data is OK but disappears on the V2 spec #365

Closed
justinyoo opened this issue Feb 17, 2022 · 2 comments · Fixed by #367 or #368
Closed
Labels
bug Something isn't working dependency resolved Request has been resolved v1.2.0

Comments

@justinyoo
Copy link
Contributor

Describe the issue

When the OpenAPI doc is rendered through the v3 spec, the multipart/form-data request body is rendered correctly. However, when it's rendered through the v2 spec, the request body is missing.

To Reproduce
Steps to reproduce the behavior:

  1. Build a function app containing a file upload field in a request body through the multipart/form-data content type.
  2. Run the function app.
  3. Access the OpenAPI document through http://localhost:7071/api/openapi/v3.json
  4. Confirm whether it renders correctly.
  5. Access the OpenAPI document through http://localhost:7071/api/openapi/v2.json
  6. Confirm whether the request body is missing.

Expected behavior

The request body should be converted to the parameters, with the in value of file, in the v2 spec.

Screenshots

When it uses the OpenAPI v3 spec, the request body is rendered with no issue.

{
  "openapi": "3.0.1",
  "paths": {
    "/pet/{petId}/uploadImage": {
      "post": {
        "operationId": "uploadFile",
        "parameters": [
        ],
        "requestBody": {
          "content": {
            "multipart/form-data": {
              "schema": {
                "$ref": "#/components/schemas/petFormData"
              }
            }
          }
        },
      }
    },
  },
  "components": {
    "schemas": {
      "petFormData": {
        "type": "object",
        "properties": {
          "additionalMetadata": {
            "type": "string",
            "description": "Additional data to pass to server"
          },
          "file": {
            "type": "string",
            "description": "File to upload",
            "format": "binary"
          }
        }
      }
    }
  }
}

However, when it uses the OpenAPI spec v2, the request body is missing – it should be converted to a parameter of file.

{
  "swagger": "2.0",
  "paths": {
    "/pet/{petId}/uploadImage": {
      "post": {
        "operationId": "uploadFile",
        "consumes": [
          "multipart/form-data"
        ],
        "produces": [
          "application/json"
        ],
        "parameters": [
          {
            "in": "path",
            "name": "petId",
            "required": true,
            "type": "integer",
            "format": "int64"
          }
        ]
      }
    }
  },
  "definitions": {
    "petFormData": {
      "type": "object",
      "properties": {
        "additionalMetadata": {
          "description": "Additional data to pass to server",
          "type": "string"
        },
        "file": {
          "format": "binary",
          "description": "File to upload",
          "type": "string"
        }
      }
    }
  }
}

Additional context

It's because the referencing NuGet package, OpenAPI.NET v1.2.3 doesn't pick up the request body schema reference. This PR over OpenAPI.NET partially fixed this issue – it only looked after the request body properties, not reference.

@sbarrettGitHub
Copy link

Hi,
Can someone confirm if this issue is affecting content-type application/x-www-form-urlencoded also? I am seeing problems when I use contentType: application/x-www-form-urlencoded in the OpenApiRequestBody. When I open the swagger page there is nowhere to enter the body. Also when I import into Postman the selected Content-Type is "none"

[OpenApiRequestBody(contentType: "application/x-www-form-urlencoded", bodyType: typeof(string), Description = "Twilio message fields", Required = true)]

@justinyoo
Copy link
Contributor Author

justinyoo commented Feb 21, 2022

@sbarrettGitHub Both #367 and #368 indeed sort out both application/x-www-form-urlencoded and multipart/form-data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working dependency resolved Request has been resolved v1.2.0
Projects
None yet
2 participants