Validator does not check a response body if response content is not present in OpenApi spec

Issue #246 resolved
Nikolay Ilyin created an issue

I have some endpoints which return nothing except the HTTP status code.

responses:
  204:
    description: OK

In the case of no schema in spec, I expect to get a validation error if the real response body is not empty.

As far as I understand this is due to ResponseValidator returning empty ValidationReport if apiResponse.content is null.

if (apiResponse.getContent() == null) {
    return ValidationReport.empty();
}

In another case, if apiResponse contains schema but the response body is missing (and the response has empty content-type) I get no error too.

if (!mostSpecificMatch.isPresent()) {
    // Validation of invalid content type is handled in content type validation
    return ValidationReport.empty();
}

I added nullable and required fields in my schema objects.

nullable: false
required:
  - foo
  - bar

But they work only during schema validation. If the response body and content-type are missing they are not used.

I’m not sure if this is an issue since perhaps this behavior is correct. In my project, I use custom MissingBodyResponseValidator to validate the response body is not empty if the schema is present in spec and vice versa.

Comments (6)

  1. Full Name

    Bump, this concerns both Request and Response validator and the second case is related to:
    https://bitbucket.org/atlassian/swagger-request-validator/issues/238/request-with-no-content-type-header-are

    Following that issue, whenever a body is present, the content-type must be present, because it’s needed for interpreting the body. A body without content-type shall be discarded by the validation process.

    If that’s the case, then this issue can be solved by requiring that the content-type must be contained in one of those listed in the spec. Which is already the case but don’t work at the moment if the spec has no content-type listed. If the spec doesn’t list any content-type, passing any content-type shall result in a validation error.

    In the current state of things, btw, following the original reasoning of Nikolay one expects that:

    errorLevelResolver.withLevel("validation.request.body.unexpected", Level.ERROR);    // Should include this situation, with the reason included.
    

    Should also signal this situation as an error.

  2. Log in to comment