It depends on the header, and on what the library is designed to handle. Let me go through each header and explain if it would make sense or not:
Content-Type make sense?
Yes and no. It's certainly nice for the server to tell us that the response is in JSON, but it is by no means a requirement. It would make sense to throw an exception if the Content-Type was something unexpected, such as
application/xml. However, to throw an exception if the content type was not specified seems overly strict. It doesn't give any security benefit either, since the application has to ensure that the consumed JSON was parsed correctly.
Specifying the charset is a "nice to have", as well, but I would wager defaulting to UTF-8 if no charset was specified should be the norm. An exception because the charset was not explicitly defined is overkill.
X-Content-Type-Options make sense?
X-Content-Type-Options header is designed to tell browsers "Don't try to figure out what this is on your own. Just trust my
Content-Type header. Your library is not a browser, it probably doesn't try to figure out what kind of content it receives based on whichever parser doesn't throw an error. The fact that the library throws an exception if this header is not present likely indicates that the behavior of "Just parse whatever you get as JSON" is hard-coded, so demanding a header that tells the library to behave how it already behaves is pointless.
Content-Disposition make sense?
No. The idea of
Content-Disposition: attachment is to kindly ask the browser to download and save a file, rather than to display it. This can be nice if you want the user to download a file (e.g. a video), rather than to display it.
In the context of a JSON response of an API, this makes no sense whatsoever. Forcing the API to instruct the browser to download a response instead of displaying it inline just makes debugging harder. It's pointless, it makes your life harder, and it has no security benefit whatsoever.
X-Frame-Options make sense?
No. The idea of X-Frame-Options is to prevent clickjacking. An API response is not an interactive website, and it makes no sense for an API consumer to demand this header to be set.
So, what should I do?
Remove these checks, plain and simple. They don't add to security and reduce compatibility.
The only checks that might make sense is the
Content-Type header, but even then I would only throw an exception if the content type is something other than
application/json, meaning that the server bothered to check and is sending something that the library knows it can't parse.