Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
I have an embedded piece of code that once upon a time worked before TLS v1 was deprecated. Note the URL download link in the subject line above was modified to protect the file. The unmodified link works fine with Chrome and Edge as the client. I have been trying to modify the code in my embedded application to use TLS v1.2 to make it work again. Below is the code snippet that I am trying to modify. I am guessing my header {} settings are incorrect. Below the code is the html response I get back from Dropbox - basically error 400. Do I need to create my own agent to do this or did I not put in the correct header {} information? I am using the typical Edge and Chrome header for 'Agent'...
Code:
yes, it was that error, but as it turns out the file still downloaded....
@terryz Thanks for clarifying. Yes, that error would indicate something went wrong with the transfer, but it sounds like curl was able to recover and complete the download successfully. It may have just been a transient network issue. Regardless, it doesn't appear to reproduce the original 400 error code from your original code, so unfortunately this doesn't seem to be representative of the original issue.
Agreed...I am wondering if my luasec client is handling the redirects or not.
The client is using lusec.
@terryz Given that the same link and headers work in another client, it does sound like your client is malforming the request somehow. Unfortunately we can't offer support for third party clients themselves, so I recommend referring to the documentation/support resources for that client for information on how to debug it. If you can get some more verbose output showing an issue on the Dropbox server side in particular though, please do share that so we can investigate.
Will do. thanks!
I managed to get the headers, see the log below from the device:
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> requestParams.method: GET https://www.dropbox.com:443/s/y5jlwu5nfr3s8xe/FAULTMSG.CSV?dl=1
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> Host: www.dropbox.com
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> Accept: */*
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> Connection: keep-alive
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> Accept-Encoding: gzip, deflate, br
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> Referer: https://www.dropbox.com/
May 22 15:50:51 err ALEOS_APPS_AAF-APPS: <UMONIoT> Failed to download file. Error code [400].
May 22 15:50:51 warning ALEOS_APPS_AAF-APPS: <RACON-ASSET-TREE> handler error detected Failed to download file. Error code [400].
May 22 15:50:51 warning ALEOS_APPS_AAF-APPS: <RACON-ASSET-TREE> handler error detected Failed to download file. Error code [400].
May 22 15:50:51 info ALEOS_APPS_AAF-APPS: <RACON-ASSET-TREE> Asset tree acknowledges ticket 1634917755 (path:'commands.UpdateControllerConfigFile', status:'-3')
May 22 15:50:51 err ALEOS_APPS_AAF-AGENT: <ASSCON> Asset ({ "iConfiguration", "iData", "iCommands" }) executing (SendData) reports error: 'Failed to download file. Error code [400].'
I do not see what is wrong - is something missing?
@terryz No, the values there appear to be valid, and nothing seems to be missing when compared to a curl sample. The only thing that looks off is that the whole URL is output under a description of "requestParams.method", but that may just be how the client is formatting its logging; it may not be representative of how it is actually formatting the real HTTP request it is sending. (The actual start line of the HTTP request should look like "GET /s/y5jlwu5nfr3s8xe/FAULTMSG.CSV?dl=1 HTTP/1.1"; and the "method" is just the "GET" part.)
The generic 400 HTML error page you're getting can be returned when the HTTP request itself is malformed, even if the intended header values themselves would be correct. For example, we've seen this when a client malforms a request by accidentally sending an extra blank line (thereby ending the headers section) before sending the rest of the actual headers. That sort of corruption may not be apparent from the client-side logging though unfortunately.
In order to simplify this in the hopes of eliminating the corruption, have you tried running your code without setting the headers yourself? You don't need to mimic a browser anyway, and the client may automatically set the header(s) that are needed (e.g., "Host").
It does appear from the log output that the full line of the GET request is indeed:
GET https://www.dropbox.com:443/s/y5jlwu5nfr3s8xe/FAULTMSG.CSV?dl=1.
Are you saying that the https://www.dropbox.com:443 should be removed from the request to be like:
GET /s/y5jlwu5nfr3s8xe/FAULTMSG.CSV?dl=1
If that is the case, then I believe I need to put in the header ":HOST" = https://www.dropbox.com:443
If the client is actually sending that full URL string in the start line, that would be incorrect. The start line in the HTTP request should only contain the method, path, and HTTP version; not the hostname/port. And the "Host" header should only contain the hostname.
For example, see that part of the first request in your working curl example for comparison:
@terryz wrote:
> GET /s/y5jlwu5nfr3s8xe/FAULTMSG.CSV?dl=1 HTTP/1.1
> Host: www.dropbox.com
OK, I will have to reformat the headers to what they need to be and give that a shot.
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!