We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.

Forum Discussion

HairyWombat's avatar
HairyWombat
Helpful | Level 6
4 months ago

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?

  • Здравко's avatar
    Здравко
    Legendary | Level 20

    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.