Dredd: Dredd ignores 'application/json; charset=utf-8' in OAS3

[tishibas]

Describe the bug
I try to use Dredd with OpenAPI3. I found that Dredd ignores the tests when the key of MediaObject is application/json; charset=utf-8.
When it is application/json, Dredd does not ignored the tests.

To Reproduce

openapi: 3.0.0
info:
  version: "0.0.1"
  title:  API
  description: 'TODO: Add a description'
paths:
  /test:
    get:
      responses:
        "200":
          description: test
          content:
            application/json; charset=utf-8:
              schema:
                type: object
                properties:
                  foo:
                    type: string

Expected behavior
A clear and concise description of what you expected to happen.

What is in your dredd.yml?

dry-run: null
hookfiles: './build/darwin_amd64/hooks'
language: './build/bin/darwin_amd64/goodman'
server: ''
server-wait: 10
init: false
custom: {}
names: false
only: []
reporter: []
output: []
header: []
sorted: false
user: null
inline-errors: false
details: false
method: []
color: true
loglevel: warning
path: []
hooks-worker-timeout: 60000
hooks-worker-connect-timeout: 60000
hooks-worker-connect-retry: 1000
hooks-worker-after-connect-wait: 100
hooks-worker-term-timeout: 5000
hooks-worker-term-retry: 500
hooks-worker-handler-host: 127.0.0.1
hooks-worker-handler-port: 61321
blueprint: './api-spec-oas3.yml'
endpoint: 'http://127.0.0.1:8888'

What's your dredd --version output?

dredd v11.2.3 (Darwin 18.6.0; x64)

[hjqgloria]

I am experiencing the same issue when I use manual run: dredd test.yaml http://localhost:5000.
Version: dredd v11.2.6 (Windows_NT 10.0.17763; x64).

[kylef]

Hi, I can confirm this is a change that needs to be done in our OpenAPI 3 parser which we hope to address this week.

The underlying cause is that the OpenAPI 3.0 specification is perhaps unclear on what a valid media type may be. The OpenAPI 3.0.0 spec states the following regarding media types:

SHOULD be in compliance with RFC6838

RFC6838 does not actually specify any syntax or BNF for media types with parameters (for example ; charset=utf-8) and thus we (and others) have interpreted a valid media type to not allow parameters as per strictly following RFC6838. Our parser interprets these media types as invalid (you'll see a warning about that) and they are subsequently discarded as they are treated as invalid.

RFC7231 does specify the parameter syntax clearly though (see https://tools.ietf.org/html/rfc7231#section-3.1.1). I've brough this up with some OpenAPI members and I think we agree that the intention was that parameters should be supported. I think it would make sense to propose a change to the OpenAPI specification to state that media types should be valid as per content-types defined in RFC7231 section 3.1.1.

[ApiaryBot]

:tada: This issue has been resolved in version 11.2.7 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: