You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Bad HTTP Content-Type header on download
I am converting, from Xamarin to MAUI, a working Android/iOS app that uses the .NET Dropbox API (specifically the Dropbox.Api V7.7.0 Nuget).
Here is a segment of working Xamarin code:
DropboxClientConfig dropboxClientConfig = new DropboxClientConfig () { HttpClient = new HttpClient ( new HttpClientHandler () ) };
DropboxClient dbx = new DropboxClient ( refreshToken, clientId, dropboxClientConfig );
…
…
using ( var response = await dbx.Files.DownloadAsync ( filepath ) )
{
return await response.GetContentAsStringAsync ();
}
On MAUI Android, the call to DownloadAsync fails with the message
Dropbox.Api.BadInputException: Error in call to API function “files/download”:
Bad HTTP “Content-Type” header: “application/x-www-form-urlencoded".
Expecting one of “text-plain”, “text-plain; charset =utf-8”, “application/octet-stream”, …..
This is the same message that I got at this point while developing the original Xamarin app. At that time, the fix was the addition of the dropboxClientConfig argument, which had the effect of replacing the native Android handler with the .NET one.
However, on MAUI, this fix does not appear to have any effect. (One suggestion in this forum is to make sure you are not on the main UI thread, and I am not.)
MAUI and Xamarin are not officially supported by Dropbox, but perhaps another user has run into this problem?
Correction: Nuget V7.0.0
HairyWombat wrote:...
Dropbox.Api.BadInputException: Error in call to API function “files/download”:
Bad HTTP “Content-Type” header: “application/x-www-form-urlencoded".
Expecting one of “text-plain”, “text-plain; charset =utf-8”, “application/octet-stream”, …..
...
Hi HairyWombat,
On different development platforms different underlying libraries may be in use for particular tasks processing implementation (including HTTP requests handling). There is no "replacing the native Android handler with the .NET one" - which is the dot net one? This is not mandatory one thing! 🙂
Usually most of the libraries use some default content type (when nothing explicitly set) and usually this is "application/x-www-form-urlencoded". Whenever this is inappropriate it should be changed to the correct one or wiped out. More stable solution is set new content type value whenever possible (it's usually possible). I don't know why .Net SDK of Dropbox tries to wipe it out for download tasks (that one you're using) - this may work, but is not so stable. You may try to set appropriate value like "application/octet-stream" (copy from here - like in upload tasks) and recompile the SDK. I haven't used and tested this in your environment, if I was in your shoes, this is the first thing I would try though - it's likely to work.
Good luck.
Thanks for that deep analysis, Здравко. I'll follow it up.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
