Including "charset=UTF-8" in Content-Type header causes an incorrect 422 response

[ashleywxwx]

Describe the bug

A few of our client libraries automatically add "UTF-8" to it's Content-Type headers, like so Content-Type: application/x-www-form-urlencoded; charset=UTF-8. When querying these mocked endpoints with this extra field, we get back a 422 with the following body. When removed, we get back the expected mocked response.

{
    “type”: “https://stoplight.io/prism/errors#UNPROCESSABLE_ENTITY”,
    “title”: “Invalid request body payload”,
    “status”: 422,
    “detail”: “Your request is not valid and no HTTP validation response was found in the spec, so Prism is generating this error for you.“,
    “validation”: [
        {
            “location”: [
                “body”
            ],
            “severity”: “Error”,
            “code”: “type”,
            “message”: “should be object”
        },
      ...
  ]
}

To Reproduce

Given this scenario file, see the failing error. The x-www-urlencoded-ok.oas2.txt is the same, minus the UTF-8 portion of the Content-Type header.

====test====
When I have a document with a Request with form-data body that should
be an array of strings (comma separated values)
And I send the correct values
And I include `charset=UTF-8` in my Content-Type
I should receive a 200 response
====spec====
swagger: '2.0'
paths:
  /path:
    post:
      produces:
        - text/plain
      consumes:
        - application/x-www-form-urlencoded
      responses:
        200:
          schema:
            type: string
      parameters:
        - in: formData
          type: array
          name: arr
          items:
            type: string
          collectionFormat: csv
====server====
mock -p 4010 ${document}
====command====
curl -i -X POST http://localhost:4010/path -H "Content-Type: application/x-www-form-urlencoded; charset=UTF-8" --data-urlencode "arr=a,b,c"
====expect====
HTTP/1.1 200 OK
content-type: text/plain

string

Expected behavior

Valid defined response returned

Environment (remove any that are not applicable):

• Library version: 3.2.3 and master from source
• OS: OSX Catalina & Mojave

Additional context

We noticed this in our 3.0.2 document, but also recreated in swagger 2.0 (shown above). If I was to take a wild guess, it might be this bit here that's not handling the content-type correctly. But, I was struggling to re-build the binary to run the test-harness after tweaking some*. I couldn't find a relevant unit test that I could manipulate around this, but if you point me in the right direction, I can try investigating some more on my end.

Side note: I was able to yarn build.binary once, but when I tried to rebuild I got "Cannot write file '...' because it would overwrite input file." errors

[XVincentX]

@andrewbell I'll look at this tomorrow but in meantime

Side note: I was able to yarn build.binary once, but when I tried to rebuild I got "Cannot write file '...' because it would overwrite input file." errors

https://github.com/stoplightio/prism/blob/master/CONTRIBUTING.md#common-issues

[ashleywxwx]

I just pulled the branch from #994 and I'm now getting back the expected 200. Thanks!