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
files/download giving 400 with an HTML page body from one host but not another
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 the...
Greg-DB
Dropbox Staff
Dropbox StaffThanks 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.
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-DBI'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.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
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
