Do not error when there is no response content but accept header is set

[jedwards1211]

Context

We would like to be able to mock test a customer's method that they're asking us to call with accept: application/json even though the method doesn't respond with a body. Their OpenAPI spec for the method has

      responses:
        200:
          description: Endpoint disenrolled successfully
          content: {}

Current Behavior

If we make the request to prism mock with accept: application/json, it complains that it doesn't know what response
body to produce:

[4:17:15 PM] › [HTTP SERVER] delete /responder_endpoints ✔ success Request received
[4:17:15 PM] › [NEGOTIATOR] ⬤ debug < Headers:
[4:17:15 PM] › [NEGOTIATOR] ⬤ debug < accept: application/json
[4:17:15 PM] › [NEGOTIATOR] ⬤ debug < accept-encoding: gzip,deflate
[4:17:15 PM] › [NEGOTIATOR] ⬤ debug < host: 127.0.0.1:4010
[4:17:15 PM] › [NEGOTIATOR] ⬤ debug < connection: keep-alive
[4:17:15 PM] › [NEGOTIATOR] ⬤ debug < Body:
[4:17:15 PM] › [NEGOTIATOR] ✔ success Request contains an accept header: application/json
[4:17:15 PM] › [VALIDATOR] ✔ success The request passed the validation rules. Looking for the best response
[4:17:15 PM] › [NEGOTIATOR] ⚠ warning Unable to find content for application/json
[4:17:15 PM] › [HTTP SERVER] delete /responder_endpoints ✖ error Request terminated with error: https://stoplight.io/prism/errors#NOT_ACCEPTABLE: The server cannot produce a representation for your accept header

Expected Behavior

We have some way to suppress this error, making prism mock respond with 200 and no body.

Possible Solution(s)

It would be nice to have a --no-accept-void-response-error CLI flag to suppress this error.

[chohmann]

@jedwards1211 thank you for reporting this. We don't think this is a feature request, but rather a bug. So rather than being able to configure whether we throw in this scenario, we think we should never throw in this scenario.

Here's what we think the behavior should be:

• if the spec defines a response body, but does NOT have a media type defined for the one requested with the accept header, we should still throw
• if the spec does not define a response body for the endpoint, we essentially ignore the accept header, and do not throw