Hi there.
I'm working in a fairly restrictive environment without the option to use a different one. Under API v1 this was not a problem, because it was far less strict and its outputs less opinionated. API v2 appears to hold itself to a higher standard of adherence to good HTTP metadata with regard to its content, which is great for more flexible and general ways to access it but terrible for me.
My technical restrictions revolve primarily around the Content-Type header, and I do not believe that the others are relevant to my issue. I am forcibly restricted to the following values, and any incoming data that does not use them is dropped before I ever see it:
text/plain; charset=utf-8
application/xhtml+xml;charset=utf-8
application/atom+xml;charset=utf-8
application/json;charset=utf-8
application/xml;charset=utf-8
application/llsd+xml;charset=utf-8
application/x-javascript;charset=utf-8
application/javascript;charset=utf-8
application/x-www-form-urlencoded;charset=utf-8
application/rss+xml;charset=utf-8
In light of this, I am of course unable to handle responses with the Content-Type "application/octet-stream", which appears to be the exclusive response type available from Content-download endpoints. I understand why this is advantageous for Dropbox since it is a great deal more friendly for serving large files, but I am dealing exclusively with raw UTF-8 JSON documents that are unlikely to ever be longer than 2048 bytes long (in fact, also an extremely generous estimate).
Is there any means that I've missed in the documentation to pass a requested content type to API v2, or cause it to serve a content type according to the file's metadata? My only alternative if not is to make use of an intermediate service for repacking my requests or stop using dropbox when API v1 is disabled, and I would really rather not.
