Take Your Search Game to the Next Level with Dropbox Dash 🚀✨ Curious how it works? Ask us here!
Forum Discussion
Error 400 using download link from embedded code
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:
local https = require("ssl.https")
local ltn12 = require("ltn12")
local options = {}
local fileMode = isbinary and "wb" or "w"
f = io.open(fulllocalpath, fileMode)
if not f then
resultstr = "Failed to open local file for writing:" .. fulllocalpath .."\r"
return false, nil, nil, resultstr
end
options = {
url = rawname,
sink = ltn12.sink.file(f),
protocol = "tlsv1_2",
headers = { --IS THERE SOMETHING WRONG HERE???
["User-Agent"] = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.190 Safari/537.36",
["Accept"] = "*/*",
["Accept-Encoding"] = "gzip, deflate, br",
["Connection"] = "keep-alive"
}
}
Here is the html response back from Dropbox:
<.DOCTYPE html> <html> <head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1" /> <title>Dropbox - 400</title> <link href="https://cfl.dropboxstatic.com/static/metaserver/static/css/error.css" rel="stylesheet" type="text/css"/> <link rel="shortcut icon" href="https://cfl.dropboxstatic.com/static/images/favicon.ico"/> </head> <body> <div class="figure"> <img src="https://assets.dropbox.com/www/en-us/illustrations/spot/target-miss.svg" alt="Error: 400"/> </div> <div id="errorbox"> <h1>Error (400)</h1>Something went wrong. Don't worry, your files are still safe and the Dropbox team has been notified. Check out our <a href="https://status.dropbox.com">Status Page</a> to see if there is a known incident, our <a href="https://www.dropbox.com/help">Help Center</a> and <a href="https://forums.dropbox.com">forums</a> for help, or head back to <a href="https://www.dropbox.com/home">home</a>. </div> </body> </html>
32 Replies
- DB-Des
Dropbox Engineer
Hi there!
Since you are receiving an HTML response, we can definitely rule out issues with TLS.
I have been unable to replicate the issue you have described. Is it possible you could enable a more verbose output in your network client? It would be helpful if we could get a better view into the raw request that the client is making.
I tired adding code to get the https request, without luck. Instead, A gathered a WireShark trace, which you can access here: https://www.dropbox.com/s/3v10bjapy7evnm6/iplogging.pcap?dl=0
Please review and let me know your thoughts.
The trace was captured using the following header (same as original, but with the addition of the 'GET' method.
-- Set the options for the HTTPS requestlocal options = {url = rawname,protocol = "tlsv1_2",sink = ltn12.sink.file(f),method = "GET", -- Add the method field to specify the HTTP methodheaders = {["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",["Accept"] = "*/*",["Accept-Encoding"] = "gzip, deflate, br",["Connection"] = "keep-alive"}}- Greg-DB
Dropbox Staff
terryz Thanks for sharing that, though unfortunately I don't think that we'd be able to determine the issue from that; a 400 like this should generally indicate that there was something incorrect about the HTTP request, but the request data would be encrypted in that capture so we couldn't read it anyway.
Perhaps instead we can try to approach this another way. Can you reproduce the issue with another client where you can inspect the actual requests that get sent? For example, I just tried to replicate the request you're sending using curl with a test shared link of my own, but it worked successfully:
curl -v --tlsv1.2 --http1.1 -X GET -L "https://www.dropbox.com/s/9kkiqvfe457hrs0/test.csv?dl=1" -o out.csv \ -H "Host: www.dropbox.com" \ -H "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" \ -H "Accept: */*" \ -H "Referer: https://www.dropbox.com/" \ -H "Accept-Encoding: gzip, deflate, br" \ -H "Connection: keep-alive"(I'm guessing you're using HTTP 1.1, but that --http1.1 option can be changed to --http2 to match if you are using HTTP 2.)
Also, you could try your code with my test shared link to see if your code works with that. If it does, it would indicate an issue with the particular shared link you're using and not the code itself.
By the way, I see you're mimicking a web browser by sending those "User-Agent" and "Referer" headers; that may not necessarily cause issues, but I can't guarantee it. Further, given that those aren't necessary, it may be good to remove them.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
