Forum Discussion

npasschyn's avatar
npasschyn
Visitor
4 years ago

Swagger compliance assertion with content type different than application/json always fails

The swagger compliance assertion has a too strict validation on the content type. Currently only the content type application/xml and application/json are allowed, otherwise the swagger compliance assertion fails.

 

According to RFC6839 the content-type can contain +json (or +xml) to signify that the document can be interpreted as json (or xml) in addition to some other schema.

https://datatracker.ietf.org/doc/html/rfc6839

https://en.wikipedia.org/wiki/Media_type#Suffix

 

I have included the response I received on an API call and a screenshot of the error we receive.

Is there a workaround for this such that the swagger compliance can still be used to validate the response in case the content-type is not application/json or application/xml?

 

I tried modifying the response headers inspired by
https://support.smartbear.com/readyapi/docs/testing/scripts/samples/modify.html
but I wasn't able to do this

 

I added a RequestFilter.afterRequest event with the following code. But editing the content type does not seem possible

context.httpResponse.contentType = "application/json;charset=UTF-8"

 

HTTP/1.1 200 OK
X-Backside-Transport: OK OK
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/vnd.sc.miss.provider.v1+json;charset=UTF-8
Date: Wed, 20 Oct 2021 12:04:05 GMT
X-Global-Transaction-ID: 526b1ebd617005ab093d96d3
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: 0
Pragma: no-cache
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-Vcap-Request-Id: d82e27c9-86b0-40f2-7038-1f2102fd6d8f
X-Xss-Protection: 1; mode=block
X-RateLimit-Limit: name=default,100;
X-RateLimit-Remaining: name=default,99;

 

Assertions
Scripting
  • richie's avatar
    richie
    4 years ago

    Hey npasschyn 

     

    Just so I understand - so you're swagger/OAS has mediatypes that include the +json suffix, but the Compliance Assertion isn't supporting requests with extended Content-Type header values?  Is that right?

     

    You can raise a Customer Support ticket to see if SmartBear can help and a New Feature request to include extended mediatype assertions -if it gets enough upvotes it could be considered for future ReadyAPI releases,

     

    The following link --> https://swagger.io/docs/specification/media-types/. indicates the supported extended media types supported by OAS currently and even explicitly mentions RFC 6368 (which is the RFC relating to vendor extensions which you appear to have in your payload) so you'd hope the Compliance Assertion would support them.

     

    However - there still might be a way to sort - at least we should be able to update your headers using an Event Handler at least. 

     

    You mentioned you tried using an event handler but it didn't work. 

     

    Can you confirm exactly what happened - what you mean by it didn't work?  Did you get errors?  No visible change?  What did it say in the ReadyAPI Log and the Error Log?

     

    Can you supply the code you used to attempt to change the header value please?

     

    Did you use RequestFilter.afterRequest or RequestFilter.filterRequest

     

    Cheers,

     

    Rich

     

  • richie's avatar
    richie
    Community Hero
    4 years ago

    Hey npasschyn 

     

    Just so I understand - so you're swagger/OAS has mediatypes that include the +json suffix, but the Compliance Assertion isn't supporting requests with extended Content-Type header values?  Is that right?

     

    You can raise a Customer Support ticket to see if SmartBear can help and a New Feature request to include extended mediatype assertions -if it gets enough upvotes it could be considered for future ReadyAPI releases,

     

    The following link --> https://swagger.io/docs/specification/media-types/. indicates the supported extended media types supported by OAS currently and even explicitly mentions RFC 6368 (which is the RFC relating to vendor extensions which you appear to have in your payload) so you'd hope the Compliance Assertion would support them.

     

    However - there still might be a way to sort - at least we should be able to update your headers using an Event Handler at least. 

     

    You mentioned you tried using an event handler but it didn't work. 

     

    Can you confirm exactly what happened - what you mean by it didn't work?  Did you get errors?  No visible change?  What did it say in the ReadyAPI Log and the Error Log?

     

    Can you supply the code you used to attempt to change the header value please?

     

    Did you use RequestFilter.afterRequest or RequestFilter.filterRequest

     

    Cheers,

     

    Rich