Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check 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 lin...
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 request
local options = {
url = rawname,
protocol = "tlsv1_2",
sink = ltn12.sink.file(f),
method = "GET", -- Add the method field to specify the HTTP method
headers = {
["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 Community Moderator
Dropbox Community Moderatorterryz 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.
I did add method = "GET" in my last test, does that need to be there?
- Greg-DB
terryz The HTTP GET method is correct for this scenario. It's often the default for HTTP clients, so even when you don't specify it, clients will usually use GET automatically.
HI Greg:
Can you send me an exact example of what the HTTP request should look like?
I may be able to approach the problem in a different way.
Thanks!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
