Support

This issue has occurred in a grand total of two servers making it extremely isolated. Therefore building an automatic detection doesn't make sense (automation only makes sense when talking about economies of scale).

Furthermore, from where Solo is sitting it cannot possibly detect this issue. It sends a PUT request and Dropbox is supposed to reply with an HTTP 200 OK message with an empty body. The broken cURL version replies back with success (200 OK) and an empty body even though it didn't bother sending any data to the server. Moreover, since chunked upload to Dropbox may take a while to assemble the file (the call to upload finalization returns before Dropbox performs the assembly) we cannot check whether the file is uploaded immediately after its creation. The only reliable way to know that it failed is having a human check the uploads a few minutes to a couple of hours later.

So, you and another guy who are affected by the broken cURL build had to contact us and we were ultimately able to tell you to use a different PHP version. That's all we can do, I'm afraid.

No, this is incorrect. cURL 7.48.0 is perfectly functional. The problem is that yours and the other guy's host have applied some patch which is not part of the official distribution that breaks the build. If it was something as easy as checking a version number, as I said above, we would have already done that.

Let me put this in the most clear terms: your host screwed up the compilation. You have an extremely rare problem that affects a grand total of 2 people out of several hundred thousand users of our software. This issue is not worth any further investigation. Just make sure that you avoid the broken build on your broken host.