Ask a Question

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

SOLVED
npasschyn
Occasional Visitor

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;

npasschyn_0-1634731752641.png

 

1 ACCEPTED SOLUTION

Accepted Solutions
richie
Community Hero

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

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

 

if this helped answer the post, could you please mark it as 'solved'? Also if you consider whether the title of your post is relevant? Perhaps if the post is solved, it might make sense to update the Subject header field of the post to something more descriptive? This will help people when searching for problems. Ta

View solution in original post

1 REPLY 1
richie
Community Hero

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

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

 

if this helped answer the post, could you please mark it as 'solved'? Also if you consider whether the title of your post is relevant? Perhaps if the post is solved, it might make sense to update the Subject header field of the post to something more descriptive? This will help people when searching for problems. Ta

View solution in original post

cancel
Showing results for 
Search instead for 
Did you mean: