nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

files/download giving 400 with an HTML page body from one host but not another

David A.114

Hi,

I'm a developer on UpdraftPlus, a WordPress backup plugin with around 250,000 users who send to their Dropbox.

We're having a problem with a few users who, when trying to download their backups, get an HTTP 400 code. We have now been given access to a site where this happens, and produced a simple test script (PHP, using curl) that makes a single POST to https://content.dropboxapi.com/2/files/download .

The test script contains all hard-coded details (e.g. the Authorization: header and download path). When this test script is run on our PHP install, it always succeeds: i.e. the expected file from the user's Dropbox is downloaded. However, when the identical PHP script is run on our user's PHP install, it always fails with an HTTP 400 error. The body returned is not JSON or error data, but HTML. If you save it and then view the HTML in a browser it looks like the screenshot I've appended at the bottom of this message (also see at https://snag.gy/QHiLqY.jpg ).

Here's a pastebin for the test script - as I say, on our server it always successfully downloads the user's file; on his, the identical script always fails with the 400 result: http://pastebin.com/FKbqK4Tx. It also always succeeds if I try the same parameters via a command-line call to /usr/bin/curl on our test machine.

Here are the headers returned from one of the failing requests, including the X-Dropbox-Request-Id header. Does this allow you to see what the cause of the problem is? On our test (succeeding) server we have PHP 5.6.29 with curl 7.47.1; on the user's (failing) server there is PHP 5.6.29 (i.e. same) and curl 7.24.0.

HTTP/1.1 400 Bad Request
Server: nginx
Date: Mon, 16 Jan 2017 23:05:23 GMT
Content-Type: text/html
Content-Length: 25457
Connection: close
ETag: "5876c90b-6371"
X-Dropbox-Request-Id: 68d4e441234efb60f425fe2163654e22
X-Robots-Tag: noindex, nofollow, noimageindex

Regards,

David Anderson

Returned body :

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Thanks for the detailed report! Unfortunately, the request ID isn't enough to see what the issue is in this case.

With issues like this, where an API call receives an HTML response, it's generally because the HTTP request for the API call was mangled such that the Dropbox API servers weren't able to recognize it as an API request.

There are a few ways for that to happen, and I suspect it's related to the different versions of curl in use here.

To help debug this, can you print out the raw HTTP request for the failing call, similar to how you shared the raw response? Be sure to redact the access token of course, but please include everything else.

David A.114

Hi Greg,

Thanks for the response. When you say that you want to see the raw HTML request, can you be more specific? I linked to a PHP script which reproduces the issue every time (when run from certain servers (but works every time from others) in my previous post; it's here: http://pastebin.com/FKbqK4Tx - there's only 6 lines of PHP needed from there to reproduce it (plus a few debug lines for more info). Were you wanting something different to that?

David

Greg-DB

I'd specifically like to see the raw HTTP (not HTML) request for the API call that results in the 400 HTTP response (which happens to contain HTML).

I tried the script you provided, but it doesn't reproduce the issue on my machine.

David A.114

Hi Greg,

Thanks. Working through that revealed the cause of the problem. When you POST to /2/files/download in the older version of Curl, with an empty body, Curl adds a header:

Content-Length: -1

The newer version of Curl does not add that header.

Explicitly adding a...

Content-Length: 0

... to the request avoids the problem. Switching to GET also avoids it (as in that case, there's no Content-Length header from the client).

I don't know which version of curl changed this behaviour. Perhaps if you tweak your API servers to treat negative content-lengths as equivalent to zero, that will help a few people out there.

David