HTTP 400 Bad Request On Download

[pchretien]

The server now returns an HTTP 400 Bad Request on a files/download call to the API because of missing Content-Type.

In DropboxRequestHandler.cs, line 443, the Content type for RouteStyle.Download is set to null while the server needs at least a text/plain.

I simply removed the line setting the Content-Type null and it worked with the default Content-Type value. I guess the long term solution should be more in line with the API requirements.

`case RouteStyle.Download:
request.Headers.Add(DropboxApiArgHeader, requestArg);

                // This is required to force libcurl remove default content type header.
                request.Content = new StringContent("");
                //request.Content.Headers.ContentType = null;

                completionOption = HttpCompletionOption.ResponseHeadersRead;
                break;

`

[greg-db]

Can you share the code you're using and the full output of the 400 error you're seeing? The DownloadAsync method is still working for me without any modifications. Thanks in advance!

[pchretien]

I was using the lib as a Nuget in a Xamarin Forms project. The library was working just fine on both Android and iPhone but then, something changed at Dropbox and we started having the following error [image] on Android. The lib continues to work just fine on iPhone.

I then switched to the lib compiled on my machine and fixed the bug with the method I described before. I will post the full stack trace when I'm back at the office ...

[greg-db]

Thanks! That error says that the client is actually sending a "Content-Type" of "application/x-www-form-urlencoded". That was never valid for API v2, and the SDK doesn't set it, so it appears that something else on the system is overriding and setting it.

In any case, the .NET SDK isn't officially supported for Xamarin, but I'll pass this along as a feature request.

[tipa]

I would very much appreciate this being fixed. Wouldn't commenting out this line be an easy fix?

dropbox-sdk-dotnet/dropbox-sdk-dotnet/Dropbox.Api/DropboxRequestHandler.cs

Line 443 in d0b609b

request.Content.Headers.ContentType = null;

[greg-db]

@tipa Thanks for the note. The team hasn't worked on implementing and testing official support for Xamarin in this SDK, but I'll add your vote to the feature request.

[tipa]

Thanks!
In addition, I think the problem originates from Xamarin using the "AndroidClientHandler" as HttpMessageHandler. So using the current lib version, a workaround would be explicitly setting the (less efficient) HttpClientHandler
dbx = new DropboxClient(accessToken, new DropboxClientConfig() { HttpClient = new HttpClient(new HttpClientHandler()) });

[cmiles]

@greg-db Fwiw thought I would leave a note here that I ran into this issue today with a Xamarin.Forms Android Application - thanks to the last comment from @tipa, using HttpClientHandler seems to have solved the problem for me...

[allanchao]

I had the same issue on Xamarin.Android native, HttpClientHandler worked for me too. Thank you @tipa!

[Orgbrat]

I also had this error or issue on Xamarin Forms Android application (UWP and iOS worked fine) , the HttpClientHandler workaround worked for me too. Thank you @tipa!

[sgarrepallygithub]

tipa, thank you very much. i spent 1 week to resolve this problem. i had code in windows desktop app. but same code could not work in Xamarin.

[nathankim0]

Thank you @tipa !! It helps me.

[tipa]

It appears that my previously posted workaround stopped working after migrating my project to a Android .NET6.

I now was able to implement an alternative workaround:

public class MyAndroidMessageHandler : AndroidMessageHandler
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
        if (request.RequestUri.AbsolutePath.Contains("files/download"))
        {
            request.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
        }
        return base.SendAsync(request, cancellationToken);
    }
}

dbx = new DropboxClient(accessToken, new DropboxClientConfig() { HttpClient = new HttpClient(new MyAndroidMessageHandler()) });

@greg-db would it be possible to fix this in the SDK as suggested here?
I can also provide a demo project if that helps you reproducing the problem

[greg-db]

@tipa Thanks for the note! We have filed this as a request with the team to officially support this SDK in Xamarin, such as potentially include that fix, but I don't have any news on that.

[tipa]

Has there been any feedback from the team on this?
The workarounds that I currently have to use (e.g. for this issue & #262) make me consider writing the API access logic myself instead of using the SDK.
That would also reduce my app size significantly (largely due to the Newtonsoft.Json dependency, see #276).
It looks like work on this SDK has been stopped apart from "Automated Spec Updates".

[greg-db]

@tipa No, I don't have any news on this. Thanks for the feedback!

You can certainly integrate against the API directly without using the SDK if you prefer. You can find the documentation for the HTTPS endpoints here.

[SmartmanApps]

@tipa Where is the AndroidMessageHandler class that you inherit from? I typed that in in Visual Studio, but it's not coming up with any suggested usings for it. I'm wanting to implement this again now in MAUI/.NET8 (having previously done so the old way in Xamarin, which as you say doesn't work anymore).

[tomreich]

@SmartmanApps I'm also experiencing this in MAUI/,NET9 on Dropbox.Api 7.0.0. Would really appreciate a fix from the Dropbox team.

[tomreich]

Anyone else with this issue in MAUI, the following should work:

new DropboxClient(refreshToken, appKey, new DropboxClientConfig() { HttpClient = new HttpClient(new SocketsHttpHandler())})